entity-framework - 架构设计 - MVC、EF、Rep、UoW、WCF、DI

Question

架构设计

为我正在组合的新架构寻找一些建议。

使用工具:

• MVC 4(如果您有 MVC 3 的示例就足够了)
• Entity Framework 4.1 (EF)
• 存储库模式
• 工作单元
• POCO(T4 自动生成)
• WCF(用于 CRUD 函数。使用具体服务类检索数据)
• 依赖注入(inject) (Ninject)
• 模拟(最小起订量)

任何其他好的工具请告诉我。

坚定使用 EF 进行 ORM，如果 EF 被证明不值得，NHibernate 将成为第二选择。

到目前为止我做了什么

1) 演示项目(MVC4、服务 DI、服务 channel 设置、 View 模型)-> 引用域项目 (2)

2)领域项目(POCO实体、领域对象、服务接口(interface))->引用业务项目(3)

3) 业务项目(WCF 服务、具体服务类、工作单元)-> 引用数据项目(4)

4) 数据项目(EF、Context + .edmx、存储库及其接口(interface))-> 查看数据库

问题 1:这是一个好的项目分解吗？ 问题 2:是否适合将上述任何项目放入括号中？ 问题 3:有什么东西应该放在我完全遗漏的地方吗？

一些旁注: 我们检索的大型记录集很容易超过 100,000 条记录。我们只是调用一个具体的服务类来提高性能，而不是通过 WCF 服务。我们超出了最大消息大小，并且通过 WCF 检索记录的时间是原来的两倍。

问题 4:是否有更好的方法来执行此操作？性能是关键。可重用性不高

域对象有一个属性，即它对应的 POCO。示例:我有一个名为“Order”的域对象。它有一个属性“OrderPOCO”，它包含所有属性。然后，域对象具有验证方法并引用必要的 CRUD 函数。

问题5:诸如“这条记录是否已存在”之类的复杂验证应该放在哪里？可以在服务本身中完成吗？

问题 6:Domain 对象是否必要？据我所知，大多数其他示例如果使用 POCO，则没有域模型。只是对这个想法有点困惑。

抱歉，这很长。任何答案都将不胜感激，但全面的答案将更加有帮助。我们可以选择工具来完成不同的事情，但让它们正确地协同工作是困难的部分。

欢迎批评!

谢谢大家

Answer 1

问题 1、2 和 3: 我经常看到只包含三层的架构布局。但是，如果您希望将领域项目层和业务项目层保持分离和解耦，以便您可以更改其中一个而不影响另一个，那么您当然应该将它们保留在单独的程序集中。然而，POCO 实体、工作单元和具体服务实现通常与应用程序的领域和业务规则非常密切相关，因此您可以考虑将这两层合并到一个程序集中。

我会将存储库接口(interface)移到业务层中，删除从业务层到数据层的引用，并让 UI 层引用数据层。然后，UI 层构造函数将具体存储库注入(inject)域/业务层。这可以使您的域/业务层免受对技术相关数据组件的引用。

问题 4: 如果性能很重要，我只会调用具体的服务类。

问题 5: 我不确定你所说的“复杂验证”是什么意思。

问题 6: EF 可以为您自动生成 POCO，并将它们放置在 .edmx 之外的另一个程序集中。请参阅this文章。这样您的 POCO 仅依赖于 T4 模板，并且不会硬耦合到 EF。