R – Incorporating ORM into a (semi) SOA architecture

Architecturenetnhibernateorm

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.

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.

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.
  • WebServices
    • Perform CRUD operations against the DB sprocs
    • Currently typically use DataSets/DataTables for their messages
  • Business Logic
    • Talks to the web services

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.

So my barage of questions is:

  • Does that approach work?

    • Do any particular ORMs favor this type of approach? Are any major ORMs particularly ill-suited to this environment?

  • 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.

    • How much of the state-tracking would an ORM provide when we stick a webservice between it and the business logic?
    • Would the objects we map to be required to provide their own state-tracking?

Best Answer

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.

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).

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).

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?

Related Topic