掺入ORM成（半）SOA架构 [英] Incorporating ORM into a (semi) SOA architecture

问题描述

我在探索一个ORM的产品（重点是NHibernate的，考虑所有选项），我相信，使用一个可能是我们的一些项目的一大好处 - 但是我有一个很难想象是多么的它会在我们的系统中播放。

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:

• 数据库。随着表......而行。
  • 的权限仅限于存储过程执行权限，我们建立存储过程与基本验证并没有进入或离开该数据库，而无需通过一个存储过程。
  • Databases. With tables... and rows.
    • Permissions are limited to execute rights on sprocs, we build sprocs with basic validation and nothing goes into or out of the database without going through a sproc.
    • 执行CRUD操作对数据库存储过程
    • 在目前通常使用的数据集/数据表为他们的消息
    • 会谈到Web服务

    添加一个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.

    所以，我的问题barage是：

    So my barage of questions is:

    • 请问这种做法的工作？

    • Does that approach work?

    • 请任何特定的ORM喜欢这种类型的方法？是否有任何大的ORM尤其不适合这个环境呢？

    难道还有其他的实现，将使一些对网络服务的客户端的ORM互动（有客户端请求的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.

    • 多少状态跟踪会，当我们把它粘和业务逻辑之间的web服务的ORM提供？
    • 会被要求我们映射对象提供自己的状态跟踪？

    推荐答案

    您的互联网服务和存储过程层已经在做大多数低级别的ORM将执行的工作：在一个强类型的方式访问数据库。这听起来像你的DataTable的Web服务回来，你正在寻找封装这些数据表为类。

    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服务允许列的发现返回它不是一个很难的项目，创建从传统的code生成技术等包装类。如果这些生成的类，从你的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).

    这是pretty的大多数我见过虽然结构不同。我见过DataStore-> ORM->业务逻辑 - > Web服务==>用于消费者相当多。这使得业务逻辑容易对数据存储写，同时提供网络服务，做决定怎么搞的业务逻辑的重任。消费者（最终用户的应用程序，无论是台式机或网络presentation）则是主要负责presentation（因为它应该是在大多数情况下）。

    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-> Web服务===> ORM->业务逻辑 - >消费。这不是我所看到的往往。我认为它的工作原理对你采取的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屋！