NHibernate架构？

Question

我打算通过使用nhibernate作为ORM来实现我的下一个项目（asp.net MVC）。由于我没有使用nhibernate的经验，我想知道我应该如何组织不同项目之间的依赖关系。 我见过这样的事情作为一个推荐的方法：

• UI取决于模型库和NHibernate
• 库依赖于模型和NHibernate

 

    ----- UI----------------------------- 
    |    |     | 
    |    |     | 
    Model NHibernate 

的问题是我做的不想让UI代码直接与nhibernate交互，所以我在想这样的事情：

• UI取决于型号和外观
• 门面取决于模型和NHibernate

----- UI -------- | | | | 模型

门面，实际上将有存储库以及封装nhibernate对象。

这听起来合理吗？有关首选架构的指南吗？

感谢名单

Answer 1

这通常是我在我的应用程序做：

• 富。核心

  • 包含域对象，业务逻辑等
  • 任何基础设施相关的组件，如Web服务，ESB产品，或数据访问没有参考
  • 有些人也把库接口在这里，但是这是一个设计选择。它可以让你在这里有您的域名服务，与库进行交互，还是脱钩NHibernate的

• Foo.Persistence

  • 引用NHibernate的
  • 库实现
  • 单位工作的HttpModule对于ASP.NET（帮助控制NHibernate在Web应用程序中的会话生命周期）

• Foo.Web

  • ，参照上述两个Foo.Core和Foo.Persistence
  • 的HttpModule参考控制NHibernate会话

Foo.Web从未与NHibernate直接交互...它始终通过存储库。使用IoC容器，您可以仅仅请求IRepository而不关心实现是什么。

Answer 2

Catharsis可能有你在找什么。

Answer 3

是的。这听起来是正确的。我从来没有使用NHibernate，但让你的UI与外观之间共享你的模型听起来不错。当然，有许多不同的方式来达到相同的目标，但你的看起来不错。 :)

Answer 4

你已经说过你打算使用MVC模式。这意味着你的UI不会与数据层（在你的情况下，NHibernate）交互。与数据层交互的是您的业务层，而您的UI将与您的业务层进行交互。

我对ASP.NET并不熟悉，所以我不能为您提供有关此预构建结构的建议，但是在我主要使用的Java中，您会让您的EJB将您的UI隔离数据层通过EJB来完成所有这些调用。

考虑隔离每层的代码。每个层次都有一个框，每个框只能通过特定渠道与其下方的框进行通信。因此，您的数据层与您的数据库进行通信，您的业务层与您的数据层进行通信，并且您的UI与您的业务层进行通信。所有这些通信都是单向的（也就是说，您的数据层不知道业务层等）。这意味着如果你想用新的实现来替换任何层，那么对程序其余部分的影响可以保持在最小。

您使用NHibernate的实际实现与MVC的使用并不相关，除了您的UI不会意识到数据如何存储或访问。