架构设计
寻找我正在整理的新架构的一些建议。
要使用的工具：
其他任何好工具都让我知道。
坚持使用EF进行ORM，如果EF证明不值得，NHibernate是第二次使用。
到目前为止我做了什么
1）演示项目（MVC4，DI用于服务，服务频道设置，视图模型） - ＆gt;引用域项目（2）
2）域项目（POCO实体，域对象，服务接口） - ＆gt;参考商业项目（3）
3）业务项目（WCF服务，具体服务类，工作单元） - ＆gt;参考数据项目（4）
4）数据项目（EF，Context + .edmx，存储库及其接口） - ＆gt;看数据库
问题1：这是一个很好的项目细分吗？ 问题2：这是将所提到的任何项目放在括号中的好地方吗？ 问题3：有什么东西应该放在我完全遗漏的地方吗？
一些旁注： 我们检索的大型记录集很容易超过100,000条记录。我们只是调用一个可以提高性能的具体服务类，而不是通过WCF服务。我们超过了最大邮件大小，加上通过WCF检索记录的时间是两倍。
问题4：有更好的方法可以做到这一点吗？表现是关键。可重用性不是
域对象具有单个属性，该属性与其对应的POCO无关。示例：我有一个名为“Order”的域对象。它有一个“OrderPOCO”属性，它包含所有属性。然后，域对象具有验证方法并引用必要的CRUD函数。
问题5 ：应该在哪里进行复杂验证，例如“此记录是否已存在”？它可以在服务中完成吗？
问题6： Domain对象是否必要？如果他们使用的是POCO，那么大多数其他示例都没有域模型。对这个想法感到有些困惑。
对不起，这很长。任何答案都将不胜感激，但全面的答案会更有帮助。我们可以选择工具来做不同的事情，但让它们正确地协同工作是困难的部分。
批评欢迎！
谢谢大家
答案 0 :(得分：2)
问题1,2和3 ： 我经常看到只包含三层的架构布局。但是，如果您希望保持域项目层和业务项目层分离和分离，那么您可以在不影响另一个的情况下更改一个层，您当然应该将它们保存在单独的程序集中。但是，POCO实体，工作单元和具体服务实现通常与应用程序的域和业务规则密切相关，因此您可以考虑将这两个层合并为一个程序集。
我会在businnes层中移动reposiroty接口，从busines层移除引用到数据层，并让UI层引用数据层。 UI层然后构造函数将具体的repostiories注入域/业务层。这可以使您的域/业务层保持对技术相关数据程序集的引用。
问题4： 如果性能很重要，我只需要调用具体的服务类。
问题5： 我不确定你的“复杂验证”是什么意思。
问题6： EF可以为您自动生成POCO，并将它们放在除.edmx之外的其他程序集中。请参阅this文章。这样，您的POCO仅依赖于T4模板，并且不会与EF硬连接。