【问题标题】:NLayer setup sanity check and questionsNLayer 设置健全性检查和问题
【发布时间】:2011-11-29 11:14:10
【问题描述】:

我正在建立一个 MVC 解决方案并尝试将其分离到逻辑项目中。到目前为止,我有以下项目:

  • MVC(表示层,Models 文件夹仅包含 ViewModel)
  • 服务(提供业务逻辑,具有接口和提供程序文件夹)
  • 存储库(用于持久性,具有接口和提供程序文件夹)
  • 域 (POCO)

mvc 层引用服务层,服务引用 repo。所有三个都引用域,以便我可以在它们之间传递 POCO。

这种设置是否有意义,因为我将来可能会使用不同的表示层,该表示层将再次通过服务层工作?

另一方面,我的域层是否允许我将一个 ORM 换成另一个而不中断?我是否认为只要 Repo 层中的 repo 类实现接口,我就可以创建一组新的具体 repo 类,它们可以与不同的 ORM 一起使用?

我的 DbContext 是否应该与 EF 实现一起存在于 Repo 层中?这是 UoW 会去的地方吗?

我的服务可以使用域 POCO 上的注释进行基本验证,还是应该使用 Fluent Validation 等工具?

最后(!)为每一层创建一个单独的测试项目是否正确(在适当的情况下)?

提前感谢所有帮助,

詹姆斯

【问题讨论】:

    标签: asp.net-mvc-3 n-tier-architecture


    【解决方案1】:

    只要您确定您是针对接口而不是实现进行开发,这肯定会起作用。

    我们正在开发与您所建议的架构相似的应用程序。

    我们的表示层使用 MVP,因此我们可以在 ASP.NET Webforms 和其他前端之间共享我们的表示器。我们使用 ServiceFactory,它使用依赖注入来创建我们的服务。这可以是 WCF 客户端代理或直接服务。如果呼叫通过 WCF 或直接进行,演示者现在不需要。

    在我们的服务层中,我们使用一个 UnitOfWork 来包装一组存储库。 UoW 也是通过 DI 构建的。

    我们使用实体框架并从中生成 POCO 对象。我们只选择不将 POCO 一直共享到表示/视图层,而仅在业务和服务层共享。从服务层来看,我们使用自定义 DTO。目前 EF 和 UoW 生活在同一个项目中。我们可以将它们移动到另一个程序集并从那里加载它们,但实际上它不会有任何区别(并且我们希望避免每次加载解决方案文件时整个“项目数量”爆炸)。

    我们在 POCO 实体和服务层(将 DTO 映射到 POCO 并可以检查数据)中执行部分验证。此外,我们在演示者和视图中的 javascript 中验证传入数据(以获得良好的用户体验)。我们目前不使用验证工具。

    是的,我们对每一层都有一个测试项目。 我们测试 Presenters、Services 和 UoW/Repositories。在我们的构建服务器上,我们运行持续集成,它在几个不同的设置中运行所有单元测试(在内存中,针对数据库,使用 WCF)。

    当然,如果您只测试您的 Presenters,这也会影响服务和数据层,但如果您模拟所有依赖项,您可以单独测试每一层(特别是对于另一层应该引发错误或其他情况的情况,这模拟整个层时要容易得多)。

    我目前唯一关注的是测试实际视图。我们目前没有以自动方式测试它们。也许我们将使用 Coded UI 测试或一些 javascript 框架。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-01-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-06-10
      • 2020-08-31
      相关资源
      最近更新 更多