Java 整个体系没啥大问题, 除了啰嗦了点. 否则也不会成为如今后端的 TOP 1 了, 虽然有历史的进程原因.
1. Servlet 规范是没法抛弃的, 这个本质上就是整个 JAVA 生态的原初理念
2. 字段不应该直接暴露, 这个和有无逻辑毫无关系, 暴露细节违反了面向对象最基础封装特性, 这个几乎没有争议
3. 面向接口编程没啥问题, Java 一些解决方案的复杂化是因为大家都过渡追求复用, 然后过度抽象. 如果你确定一个东西不会更改, 你完全就可以直接 new, 你看你的代码是不是到处都在直接构造 String 这些基本类型. 最佳实践都是人们踩过的坑后慢慢总结出来的, 因此公司项目还是要以规范性为主, 因为你需要和其它人协作, 多人协作一致性是最重要的一条原则.

最快确定一个人是否完整,系统且认真的学习过 JavaScript, 而不是将其当作玩具语言, 到处复制粘贴代码. 面试如果招聘前端, 如果原型都无法解释清楚, 肯定会被我淘汰, 因为这个玩意非常简单, 这个都搞不明白, 说明要么智力有问题, 要么根本没花心思在自己使用的工具上. 实际项目手动使用 prototype 非常少, 但它总是在起作用. 编写兼容库的时候, 会通过补全原型来模拟一些原生方法.

编译器没有获取足够的信息, 并不知道自动给你填充足够的类型.
实在想跳过去可以这么做: ref({} as unknow as ICategoryFormData)

另外我们的项目 Query 和 Command 是分开的, 用了不同的数据库, 大部分时候并不需要复杂的 Join

正常直接使用 EFCore, 有需求的情况下直接在 Context 上直接调用原生 SQL, 我们的项目需要根据场景切换数据库(Oracle/MySql/SQL Server/MongoDB), 而且写 SQL 的时候都会使用 Repository 包一层, 按照实际引用的 Provider 做不同的适配, 如果要追求极致的性能, 我直接用 ADO.ENT 了, 另外简单的项目使用 LinqToDB. Framework 时代用 Dapper 比较多, Core 后基本没用过了

这些哲学问题, 有文字记录以来的贤者都深入思考过, 现在哲学的存在主义也试图回答这个问题. 不同时代, 不同境况的人都试图描绘出自己看到的大象的模样, 就这样争吵了几千年. 存在先于逻辑吗? 也许永远不会有答案, 但对这个问题进行深入思考, 还是有意义的, 至少可用让自己活得没有那么糊涂.

应用层按照功能尽可能的多公开数据, 一个模型就不会有太多 dto, 正常情况下就只会有 CreateEntityDto, UpdateEntityDto 和 EnttityDto, 为了节省带宽按需求获取部分参数, 则在上面包一层 GraphQL, 验证的逻辑安全可以不写到 Dto 上, 而是直接使用 Fluent Validation API 使用代码定义, 而不是总是使用 Atttribute, 即便使用 Atttribute, 也不应该对 Dto 做逻辑校验, 一般只做简单的数据格式校验, 这种情况, 重复写多次 Attribute 并不是什么问题, 另外你也可以给 Dto 分层, 使用继承和泛型组合. C#类型运算太弱了, 几乎等于没有, 没法像 TypeScript 那样领域, TypeScript 的类型运算骚操作太多, 对于 C#这种纯静态语言(不考虑 DLR), 按照 TS 的逻辑写肯定是不大行得通的

你不说语言, 谁知道你用的啥?

@petrichor08 自己编写协议库非常麻烦, 除非你需要长期维护一个底层库, 否则建议直接去看你对应语言的第三方开源库, 从哪里开始研究比较靠谱, 主要是要处理的通讯边界条件太多, 要编写的靠谱非常困难. 我之前也尝试过自己写, 然后发现个人精力有限, 最终还是选择了研究第三方库. C#有很多靠谱的 BACnet 库, 其它语言也应该有. 我主要是一直在尝试订阅模式, 在一些项目中发现 UDP 会击穿整个网络的交换机, 后来很多项目对延迟要求不太高(超过 5s),就直接使用了轮询!

@petrichor08 一部不需要管协议的事情, 找一个你使用的语言的库, 然后将你自己的客户端接入 BACnet 网络, 然后就可以读写其它设备的属性(value 是一个特殊属性), WhoIs 命令发出去喊一声就知道网络有那些设备了. 除非你需要编写解析协议的库, 否则并不需要知道具体报的格式, 如果想要知道报文格式, 直接去看 BACnet 官方协议, 这个协议存在历史非常悠久了. 商业大楼的楼宇控制一般会使用这个协议, 或者 OPC 协议.

@moyechen 我现在的想法是先将整个进程 dump 出来, 然后在使用分析工具找到已加载的字节码, 然后看不能不能反编译字节码

@moyechen 好些, 我先试一试, pyc 文件也被覆盖掉了, 就比较悲催

@klo424 UI 库方面, 微软从 Windows 8 开始, 折腾的是比较离谱, 特别是 Windows Phone 的败局, 得罪了很多开发者.

@INCerry 和一堆不用.NET 的解释, 完全是浪费时间! 我各个语言都用, 除了廉价的靠谱劳力没有 Java 多, 我没发现有啥缺点! 微软自己总是作死, 这点谁也没有办法. 如果要我说, 我觉得生态从.NET 1.0 到.NET Framework 4.8 再到现在.NET 7 就没有什么大的变化, 也不存在中断, 唯一问题是微软换了太多次 UI 库了(包含 Web 层面), 这个导致很多做 APP 开发的人跑掉了, 另外微软在 Mobile 上的败局导致了今天的局面, 和 Java 的竞争失败纯粹是微软自己的策略问题, 出来比 Java 晚, 开源太晚, 人家已经有现成的方案, 为什么要花费巨大的成本更换呢? 另外就是失去了话语权, 这点其实很致命, 是微软 90 年代自己结了太多怨了. 不过大部分人都是白嫖党, 在免费和没有更好的选择下, 你看还不是乖乖选择了 VSCode, TypeScript 这种微软出的东西.

@czqzero 感觉目标太小的话只能提高照片的分辨率, 否则识别精度应该会很差!

@bellfahle 就和 @popok 提供的图片差不多, @popok 有现成的话, 我就去找下链接, 然后扔给她, 让她自己去咨询, 我自己也没时间帮她折腾. 我感觉原理上应该是没问题的, 我也在网络上搜索了一下, 没找到合适的成品解决方案.

@Vincent103 太多了,如果要入门的话, 可以从 JSON.NET 开始, 然后研究 BCL(这个里面有非常多值得学习的地方), 或者 ASP.NET Core, 这些都比较容易, 再然后想要深入可以研究 runtime, 我在研究的有 ABP(C#)和微软的 Dapr(Go)