将 ORM 合并到(半)SOA 架构中 [英] Incorporating ORM into a (semi) SOA architecture

问题描述

我正在探索 ORM 的产品(专注于 NHibernate，考虑所有选项)，并确信使用 ORM 可能对我们的某些项目有很大好处——但是我很难想象如何它会在我们的系统中播放.

I'm exploring the offerings of an ORM (focusing on NHibernate, considering all options) and am convinced that using one could be a great benefit for some of our projects--however I'm having a hard time picturing just how it would play in our system.

我的理解是 ORM 最适合用于将数据库和业务逻辑粘合在一起.这假设业务逻辑可以访问数据库，但在我们的系统中，我们有网络服务卡在中间.

My understanding is that an ORM is ideally used to glue together a database and business logic. This assumes the business logic has access to a database, but in our system we have web-services stuck in the middle.

我们当前的系统相当简单.我们是 .NET 直通并拥有:

Our current system is fairly simple. We are .NET thru-and-thru and have:

• 数据库.带有表格...和行.
  • 权限仅限于对 sproc 的执行权限，我们构建具有基本验证的 sproc，没有任何东西在不经过 sproc 的情况下进出数据库.
  • 对数据库进程执行 CRUD 操作
  • 目前通常使用数据集/数据表来处理他们的消息
  • 与网络服务对话

  将 ORM 添加到组合中似乎在逻辑上将其置于数据库和 Web 服务之间.因此，客户端将向服务发出请求，服务将使用 ORM 以对象而不是数据表的形式检索结果，并且客户端将从 Web 服务接收对象.

  Adding an ORM to the mix seems to logically put it between the database and webservice. So the client would make a request to the service, the service would use the ORM to retrieve the results as objects instead of as DataTables, and the client would receive objects from the web-service.

  所以我的问题是:

  • 这种方法行得通吗?

  • Does that approach work?

  • 是否有任何特定的 ORM 喜欢这种类型的方法?是否有任何主要的 ORM 特别不适合这种环境?

  是否有另一种实现将一些 ORM 交互放在 Web 服务的客户端(让客户端从 ORM 提供者请求一个对象，并让 ORM 提供者包装 Web 服务通信)?

  Is there another implementation that would place some of the ORM interaction on the client-side of the web-service (have the client request an object from the ORM provider and have the ORM provider wrap the web-service communication)?

  我们当前的工作单元侧重于数据表及其行状态跟踪.

  Our current unit-of-work focuses on DataTables and their row-state tracking.

  • 当我们在 ORM 和业务逻辑之间插入 Web 服务时，它会提供多少状态跟踪?
  • 我们映射的对象是否需要提供自己的状态跟踪?

  推荐答案

  您的 Web 服务和存储过程层已经在执行低级 ORM 将执行的大部分工作:以强类型方式访问数据库.听起来您从 Web 服务获取 DataTables，并且您希望将这些 DataTables 封装到类中.

  Your webservice and stored procedure layers are already doing most of the work that a low level ORM would perform: accessing the database in a strong typed fashion. It sounds like you get DataTables back from the web service and you are looking to encapsulate those DataTables into classes.

  您从大多数 ORM 产品提供的自动生成"功能中获得的帮助很少，因为它们通常面向直接从 SQL 源创建类.另一方面，如果您的 Web 服务允许发现返回的列，那么从传统的代码生成技术创建这样的包装类并不是一个困难的项目.如果这些生成的类派生自 ORM 的基本类型，您就可以使用基础设施的其余部分(实体集合、工作单元等).

  You would get very little help from the "autogeneration" capabilities that most ORM products provide as they are usually geared toward creating the classes directly from a SQL source. On the other hand, if your web services allow the discovery of the columns returned it isn't a hard project to create such wrapper classes from traditional code generation techniques. If these generated classes derive from the base types of your ORM you may be able to use the rest of the infrastructure (entity collections, unit of work, etc).

  这与我见过的大多数架构大不相同.我看过DataStore->ORM->Business Logic->Web Service==>Consumer 用的挺多的.这使得业务逻辑易于针对数据存储编写，同时提供负责决定如何参与业务逻辑的繁重工作的 Web 服务.使用者(最终用户的应用程序，桌面或 Web 演示文稿)然后主要负责演示文稿(在大多数情况下应该如此).

  This is pretty different from most of the architectures I have seen though. I have seen DataStore->ORM->Business Logic->Web Service==>Consumer used quite a bit. This makes the business logic easy to write against the data store while providing web services that do the heavy lifting of deciding how to engage the business logic. The consumer (the end user's application, either desktop or a web presentation) then is mostly responsible for presentation (as it should be in most cases).

  另一方面(除非我误读了)，您似乎对 DataStore->Sproc->WebServices===>ORM->Business Logic->Consumer 感兴趣.这不是我经常看到的.我认为它不利于您以您正在考虑的方式采用 ORM.

  On the other hand (unless I have misread) it seems you are interested in DataStore->Sproc->WebServices===>ORM->Business Logic->Consumer. This isn't something I have seen often. I think it works against your adopting ORM in the manner it appears you are thinking about.

  我是否遗漏了什么，或者大部分业务逻辑是否真的在客户端上执行?

  Am I missing something, or is most of the business logic really being executed on the client?

  这篇关于将 ORM 合并到(半)SOA 架构中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！