C# n层解决方案&x2B；征求意见

我有机会开发一个稍微复杂的项目，并一直在研究各种方法，我可以用来解决这个项目。通常我会使用传统的三层方法，但在花了一些时间研究了各种选择之后，我有了一个线索，某种ORM可能更适合，我正在考虑nHibernate。然而，我正在寻找一些关于实施nHibernate的指导，更具体地说，我将如何与nHibernate一起构建我的BL和DAL

使用nHibernate，我将创建我的对象（或DTO？），并在DAL中使用nHibernate方法进行CRUD交互。但我不能理解的是，DAL中定义的对象可能更好地位于BL中，也就是说，在那里可以轻松执行验证和其他内容，我只是使用各种ObjectFactory/ObjectRepositories中的DAL。不幸的是，在我读过的许多文章中，似乎都没有提到或忽略这一点，我有点困惑

---

在三层系统中使用nHibernate时，什么是更被接受或更容易实现的方法？或者，通过业务层将对象从数据层公开到演示文稿的传统方法是什么？

我与nHibernate的个人经历使我决定，数据访问层变得如此之薄，以至于我无法将其与业务逻辑分离。您的大部分数据访问代码已经被分离到xml文件（或其他各种不同的方法，如Fluent nHibernate）中，并且由于连接几乎是透明处理的，因此使用criteria对象的查询很少超过几行。

我怀疑您想得太多了。nHibernate基本上是一个非常简单的工具；它的基本功能是管理数据库中记录与数据模型中类似结构对象之间的序列化。基本上就是这样。没有任何东西表明您不能将Hibernate对象封装在业务层对象中进行验证；那很好。但是要理解验证和序列化的操作是根本不同的；Hibernate管理序列化组件，并且做得很好。可以将Hibernate序列化对象视为有效的“原子”。

---

基本上，您想要的是：nHibernate是您的数据访问层。（当然，您可以在数据访问层中使用其他数据访问方法，但如果要使用Hibernate，则应使用基本的Hibernate数据设计，即执行记录到对象的相对简单映射的简单对象。）如果您的设计要求使用不同的设计（深度合成的对象依赖于多个重叠表）这不符合Hibernate的要求，您可能必须放弃使用Hibernate；否则，只需使用nHibernate所暗示的简单POCO方法。

我已经在生产中使用了基于nHibernate的应用程序，虽然它比大多数DAL更好，但我已经到了无法再推荐任何人使用nHibernate的地步使用会话来执行任何高级应用程序都是荒谬的。对于简单的应用程序来说，NHibernate对于企业应用程序来说是微不足道的，其复杂性是无法想象的

在这一点上，我决定根据范围使用3种不同的选择来解决数据访问问题，使用文档数据库（目前特别是Raven）进行全面应用，使用LinqToSql进行中等数量的数据访问，以及使用原始ADO.NET连接，并取得了巨大成功

作为参考，这些陈述是在我用NHibernate开发了2年多之后，每次我觉得我完全理解NHibernate时，我都会遇到一些新的限制或我必须处理的巨大活动扳手。这也让我意识到我开始设计与NHibernate相关的应用程序使用ORM使我的应用程序的设计不受数据库的支配，这是我的首要原因之一

---

不必处理NHibernate的复杂性带来的会话管理是我迁移到RavenDB的最大好处之一。有了Raven，除了在执行极端性能优化或批处理操作时，您几乎不需要管理会话。

我喜欢让体系结构出现，但如果我今天开始使用NHibernate，那么这就是我在典型的ntier asp.net mvc项目上的初始架构

首先，我会尽量避免控制器中的域代码。因此，我会在业务层上创建一个服务层/门面，控制器（或代码隐藏）会对其进行调用。我会将我的对象分为两种类型：1）具有写端使用的业务行为的对象，和2）ViewModel/DTO对象，用于显示数据和获取初始数据条目。这些DTO将具有所有视图特定的关注点，如简单的验证属性等。。。DTO可以有自己的NHibernate映射，也可以使用NHibernate的AliasToBean特性进行投影。一旦在操作中通过控制器，它们就会映射到业务对象

---

至于数据访问层，我可能会在服务层直接使用NHibernate。除非我知道必须能够交换ORM，否则我不会使用存储库模式。NHibernate已经是一个持久性抽象。在上面放一个存储库会让你放弃很多功能。

我的02美分（因为没有适合所有人的答案）：

DAL应该只负责数据检索和持久性

您可以拥有一个包含DAL填充的模型（对象）的库