2

架构设计

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

使用工具：

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

任何其他好的工具让我知道。

如果 EF 被证明不值得，那么坚决将 EF 用于 ORM，而 NHibernate 是第二个选择。

到目前为止我做了什么

1) Presentation Project (MVC4, DI For services, Service Channel setup, View Models) -> 参考领域项目(2)

2）领域项目（POCO实体、领域对象、服务接口）->参考业务项目（3）

3) 业务项目（WCF 服务、具体服务类、工作单元）-> 参考数据项目(4)

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

问题1：这是一个好的项目分解吗？ 问题 2：这是将任何提到的项目放在括号中的好地方吗？ 问题 3：有什么东西应该放在我完全遗漏的地方吗？

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

问题4：有没有更好的方法来做到这一点？性能是关键。可重用性不是

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

问题 5：应将“此记录是否已存在”等复杂验证放在哪里？可以只在服务本身中完成吗？

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

对不起，这很长。任何答案将不胜感激，但全面的答案将成倍增加。我们可以选择工具来做不同的事情，但让它们正确地协同工作是困难的部分。

欢迎批评！

谢谢你们

4

1 回答 1

2

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

我会将存储库接口向上移动到业务层，从业务层删除对数据层的引用，并让 UI 层引用数据层。然后，UI 层的构造函数将具体的存储库注入到域/业务层中。这可以使您的域/业务层保持对依赖于技术的数据组合的引用的清洁。

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

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

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

于 2012-06-03T20:32:55.927 回答