我理解抽象和分离关注点和单元测试的必要性,但是,在我看来,将实体和上下文分成 2 个项目有点过度设计?
我可能真的错过了一些东西,但这是因为你想对不同的 ORM-s 开放吗?
非常感谢您的澄清。
我理解抽象和分离关注点和单元测试的必要性,但是,在我看来,将实体和上下文分成 2 个项目有点过度设计?
我可能真的错过了一些东西,但这是因为你想对不同的 ORM-s 开放吗?
非常感谢您的澄清。
我更喜欢将基础设施与域模型(核心项目)放在一个单独的项目中,而不仅仅是一个单独的文件夹中的主要原因很简单:通过编译器强制执行我的设计。
我有一个设计规则,基本上就是依赖倒置原则。不要依赖于低级实现(例如在基础设施中发现的那些),而是依赖于抽象(接口)。另外,不要让你的抽象依赖于细节;有细节依赖于抽象。基础设施服务实现中如何以及哪些基础设施用于给定抽象的详细信息。
抽象说什么;实现说明如何。
什么:我需要发送一封电子邮件。ISendEmail接口
如何:我想使用 SMTP 协议 SmtpEmailSender 类(实现 ISendEmail)
如何:我想使用 SendGrid API SendGridEmailSender 类(实现 ISendEmail)
那么,在单个项目中,您将如何确保实现依赖于接口,而不是相反?
您将如何确保您的域类不直接引用或使用基础设施类型?
我不知道有办法做到这一点。
但是,如果您将它们放在单独的项目中,并且您的实现细节项目依赖于抽象和模型项目,那么您现在已经解决了问题。编译器不允许 Core 项目引用 Infrastructure 项目中的任何内容,因为它会创建循环依赖项。
这种约束可以帮助开发人员做正确的事情并让他们陷入成功的陷阱,即使他们没有完全理解依赖倒置原则是如何工作的或者为什么它很重要。
对于我为实际工作而构建的任何非演示应用程序,我从未发现 3 个项目(Core/Infra/UI)过度设计。只有3个项目。