应用层按照功能尽可能的多公开数据, 一个模型就不会有太多 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)

@villivateur C#的兼容性太高了, 极少数情况(我能想起来的不会超过 10 处)为了修复一些原来的问题才会破坏兼容性, 只要不去研究 UI 框架, Web 框架, 基本上没啥问题! 我给你说的几本书基本没有 UI 框架的, 都是语言和基础库层面的东西, 不涉及到什么版本问题. .NET Framework 的 API 兼容性也很高, 我现在用的是.NET 6.0(它本质上.NET Core 5.0), 基本上回头看, 大部分还是原来那些! 另外微软的 UI 层面的库(Web Form), WPF, UWP 我是不建议你去深入研究的, 我感觉微软的 UI 部分被人诅咒了, 都做的些什么玩意!!!

@GeruzoniAnsasu 不是的, 我看过她拍的那个视频, 那个鱼苗其实用机器识别肯定是可以识别的(2 厘米左右长), 一个 1.5m 直径的盆里面大概 1,200 尾, 因为我搞过自动驾驶的点云识别,主要是去重和成本是否可行! 他们这个行业很多都是用人数的, 因此成本可以在后期复用摊薄研发成本.

@GeruzoniAnsasu 买鱼苗不是这个流程

@GeruzoniAnsasu 实际养鱼的反正没人这么用, 具体原因我也不大清楚!

@kop1989smurf 你可能没有养过鱼. 养鱼的每年都需要购买鱼苗, 鱼苗用杯子人一尾一尾的数, 然后放到一个更大的鱼盆里面, 在然后放进鱼塘. 这个过程中, 清晰度, 全景都不是特别大的问题. 核心在准确率, 如果准确度太低 90%一下, 就完全失去了实用价值.

@INCerry 嗯, 这个也不错. 只要不去看什么《 C#高级程序设计》那本 2000 页候的辣鸡就行, 它什么都想讲, 啥也没讲好! 但我觉得《.NET 探秘 : MSIL 权威指南》《.NET 内存管理宝典》.NET Core 底层入门》其实都不适合还在没有深厚功底的程序猿, 至少需要很多年代码, 基础牢固, 否则完全就是云里雾里, 另外好多书籍都不更新, 英文也停了. 后面发现代码要写的漂亮需要看架构设计. 高并发需要看分布式. 扣性能细节需要看底层书籍. 越学越感觉是个无底洞, 不过基础越牢固, 学其它也越容易, 但任何一个方向, 到了深入后, 都会越来越难, 各种细节的复杂性(Complexity)很容易淹没一个人有限的精力, 有时候还是需要跳出来.

@kingjpa 主要是罗技这个 SB 公司, 维修服务都不提供, 而且网上非常多人反映他们用的微动是国产的辣鸡, 所以非常容易坏!

@INCerry 你看的这个系列我叶基本都看过, 三本就够: 《深入理解 C#》《 CLR via C#》《.NET 设计规范 : 约定、惯用法与模式》, 如果还要加一本就是《.NET Core 底层入门》, 其实看这些书太浪费时间了, 我现在只看官方文档, 然后主要还是研究大学本科的 5 门核心课程, 其它书籍都不看了, 直接去看源代码! C# IN Depth 的确是难道的好书, CLR via C#需要更新版本了, 而.NET 设计规范我觉得是任何合格的 C#程序员都应该看一看的书籍!