代码之家 › 专栏 › 技术社区 › STW

将ORM合并到(半)SOA架构中

orm architecture nhibernate .net

STW · 技术社区 · 17 年前

我正在探索ORM的产品(专注于NHibernate,考虑到所有的选择),我相信使用一个ORM对我们的一些项目可能会有很大的好处——但是我很难想象它在我们的系统中会如何发挥作用。

我的理解是,ORM理想地用于将数据库和业务逻辑粘合在一起。这假设业务逻辑可以访问数据库,但在我们的系统中,Web服务一直处于中间位置。

我们目前的系统相当简单。我们是.NET直通和直通,并且有:

数据库。有桌子…和行。
- 权限仅限于对存储过程执行权限,我们使用基本验证来构建存储过程,并且在不经过存储过程的情况下,任何内容都不会进入或退出数据库。
的集成
- 对数据库存储过程执行CRUD操作
- 当前通常将数据集/数据表用于其消息
业务逻辑
- 与Web服务对话

向组合中添加ORM似乎在逻辑上把它放在数据库和WebService之间。因此,客户机将向服务发出请求,服务将使用ORM以对象而不是数据表的形式检索结果,客户机将从Web服务接收对象。

所以我的问题是:

这种方法有效吗?
- 任何特定的窗体是否支持这种类型的方法?是否有任何主要的窗体特别不适合这种环境?
是否有另一个实现将一些ORM交互放置在Web服务的客户端(让客户机从ORM提供程序请求一个对象,并让ORM提供程序包装Web服务通信)?
我们当前的工作单元主要关注数据表及其行状态跟踪。
- 当我们在一个ORM和业务逻辑之间插入一个WebService时,它将提供多少状态跟踪?
- 我们映射的对象是否需要提供自己的状态跟踪?

2 回复 | 直到 17 年前

Godeke 17 年前

您的WebService和存储过程层已经完成了低级ORM将要执行的大部分工作:以强类型方式访问数据库。听起来像是从Web服务中获取了数据表,并且希望将这些数据表封装到类中。

大多数ORM产品所提供的“自动生成”功能对您几乎没有帮助,因为它们通常是针对直接从SQL源创建类的。另一方面,如果您的Web服务允许发现返回的列,那么从传统的代码生成技术创建这样的包装类并不难。如果这些生成的类派生自ORM的基本类型,那么您可能能够使用基础结构的其余部分(实体集合、工作单元等)。

这与我所看到的大多数体系结构非常不同。我见过数据存储->ORM->业务逻辑->Web服务==>消费者使用了很多。这使得在提供Web服务的同时,可以很容易地针对数据存储编写业务逻辑,从而决定如何使用业务逻辑。消费者(最终用户的应用程序,无论是桌面还是Web演示)则主要负责演示(在大多数情况下应该是这样)。

另一方面(除非我读错了),您似乎对数据存储->存储过程->WebServices===>ORM->业务逻辑->消费者感兴趣。这不是我经常看到的。我认为这对你采用ORM的方式起到了反作用。

我是否遗漏了一些东西,或者大部分业务逻辑确实是在客户机上执行的?

Stefan Moser 17 年前

我建议不要在你的情况下使用ORM,这是来自一个经常使用NHiberinate的人。在当前的设置中,为了使应用程序正常工作,您必须跳过几个环,而且您将无法从一个良好的ORM(如NHibernate)提供的大多数功能中受益。

使用存储过程和ORM虽然可以完成,但是很难配置ORM,并且很难从它所做的工作中拉断ORM的肌腱。
当使用NHibernate时,通过可到达性的持久性是一个巨大的好处,但是由于您的域层是“断开的”,所以您将无法使用它。
nhibernate是基于idbConnection的,因此尝试将其连接到Web服务上的客户端将使您无法使用会话(工作单元)。

如果您试图传递对象而不是数据表,为什么不使用DTO呢?这将为您提供强类型对象,但仍将在您的设置中工作。