nHibernate,一个n层解决方案+请求建议

时间:2010-10-20 16:24:43

标签: c# asp.net nhibernate orm

我有机会开发一个稍微复杂的项目,并且一直在调查我可以用来解决这个项目的各种方法。通常情况下,我会使用传统的3层方法,但是花了一些时间环顾各种选项之后,我有一种暗示某种ORM可能更合适,我正在考虑nHibernate。但是,我正在寻找有关实现nHibernate的一些指导,更具体地说,我将如何与nHibernate一起构建我的BL和DAL。

使用nHibernate我会在我的DAL中创建我的对象(或DTO?)并使用nHibernate方法进行CRUD交互。但是我无法理解的是,DAL中定义的对象可能更好地位于BL中,即可以轻松执行验证和其他内容,并且我只使用各种ObjectFactory的/ ObjectRepositories中的DAL 。不幸的是,通过我读过的很多文章似乎都没有提到或绕过它,我有点困惑。

在3层系统中使用nHibernate时,更容易接受或更容易实现的方法是什么?或者,通过业务层将对象从数据层暴露给表示的传统方法是什么?

5 个答案:

答案 0 :(得分:1)

我对nHibernate的个人经验让我决定数据访问层变得如此之薄,以至于我从没有把它与业务逻辑分开。您的大部分数据访问代码已经分为xml文件(或其他各种独特的方法,如Fluent nHibernate),并且由于连接几乎透明地处理,因此使用条件对象的查询很少会超过几行。

答案 1 :(得分:1)

我怀疑你是在思考这个问题。 nHibernate基本上是一个非常简单的工具;它基本上做的是管理数据库中记录与数据模型中类似结构化对象的序列化。基本上就是这样。没有什么说你不能将Hibernate对象封装在Business Layer对象中进行验证;那很好。但要明白,验证和序列化的操作根本不同; Hibernate管理序列化组件,并且做得非常好。您可以将Hibernate可序列化对象视为有效的“原子”。

基本上,你想要的是:nHibernate是你的数据访问层。 (当然,您可以在数据访问层中使用其他数据访问方法,但是如果您要使用Hibernate,则应该遵循基本的Hibernate数据设计,即执行相对简单的记录映射的简单对象如果你的设计要求你使用不同的设计(深度合成的对象依赖于多个重叠的表),这些设计不能很好地映射到Hibernate,你可能不得不放弃使用Hibernate;否则,只需采用nHibernate暗示的简单POCO方法。

答案 2 :(得分:1)

我很喜欢让架构出现,但如果我今天使用NHibernate启动它,这就是我的初始架构在典型的ntier asp.net mvc项目中的样子。

首先,我会尝试尽可能多地保留控制器中的域代码。因此,我将在控制器(或后面的代码)调用的业务层上创建一个服务层/外观。我将我的对象分成两种类型:1)具有在写入侧使用的业务行为的对象,以及2)用于显示数据和获取初始数据条目的ViewModel / DTO对象。这些DTO将具有所有视图特定问题,如简单验证属性等...... DTO可以有自己的NHibernate映射,或者可以使用NHibernate的AliasToBean功能进行投影。一旦它们在操作中通过控制器,它们就会映射到业务对象。

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

答案 3 :(得分:0)

我在生产中使用基于NHibernate的应用程序,虽然它比大多数DAL更好,但我不能再推荐任何人使用NHibernate了。使用会话进行任何高级应用程序所需的复杂性是荒谬的。对于做简单的应用程序,NHibernate对于企业应用程序来说非常简单,复杂性远远超出了图表。

此时我已决定使用文档数据库(特别是当前的Raven)进行全面应用,使用LinqToSql进行中等数据访问以及处理琐事,根据范围选择3种不同的数据访问访问我实际上使用原始ADO.NET连接非常成功。

作为参考,这些陈述是在我使用NHibernate花了2年多的开发时间之后,每当我觉得我完全理解NHibernate时,我会遇到一些新的限制或我必须做的巨型扳手处理。这也让我意识到我开始设计有关NHibernate的应用程序,这是我使用ORM使数据库无需设计应用程序设计的最大原因之一。

不必处理具有NHibernate复杂性的会话管理一直是我迁移到RavenDB的最大好处之一。使用Raven,您几乎不需要管理会话,除非您正在进行极端性能优化或使用批处理操作。

答案 4 :(得分:0)

我的02美分(因为没有适合所有人的答案):

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

你可以有一个包含你的模型(对象)的库,它由DAL填充,但是松散耦合(理论上,你应该能够使用其他技术编写一个新的DAL并插入它而不是NHIBERNATE,即使你不去)

for client< - > BL谈话,我会认真建议观点/ dto以避免与客户的模型耦合(信任,我......我正在清理像这样的应用程序,这是地狱)

无论如何..我正在谈论我们在这里使用的情况遵循这种结构:

客户(winforms和web)< - >查看/演示者< - >使用消息的WCF服务< - > BL< - > DAL