使用SOA（Microsoft CRM）从2层NHibernate迁移到3层的推荐方法是什么？

Question

Given a (current) project that implements a 2-tier architecture with a well-separated on-tier business layer following the typical generic DAO architecture as pioneered by Bill McCafferty on CodeProject and explained briefly in chapter 10 of NHibernate in Action.

This project must be moved to do CRUD operations and business logic through Microsoft CRM as middle tier using web services. Custom objects and methods are defined in the CRM to mimic the current situation.

I don't think it's a good idea to start moving the POCO's back and forth the same way we used to do. Also, features as lazy loading, caching and concurrency all have to be treated differently. Considering that we have to minimize calls between middle-tier en presentation layer bring around another challenge.

Implementing DTO's seems the right cause of action, but requires a long path (plus a learning path for the team). I've done SOA projects before, but now I'm looking for the path of least resistance. Can we continue to use NHibernate, even if direct DB connection will not be an option? Will we have to rethink the design, or are disconnected entities, introduced in .NET 4.0 perhaps an option? How painless can it become?

Answer 1

Take a look at MS CRM SDK 4.0.12, in Reflector too. They went quite a long way to a proper ORM there, CRUD and Linq including. There are many subtle (and not-so-subtle) differences with NH there, and it isn't yet plugin-trained, but at least you can borrow some ideas.

Answer 2

We use XRMLinq - http://www.xrmlinq.com . It builds your DTO objects and you can then use LINQ syntax to query against them. The framework automatically converts your LINQ queries to FetchXML queries against the CRM webservices. The DTO objects are created as partial classes, so you can add your own logic that will survive regenerations.

Another tip: use custom workflow activities for your business logic where possible. Instead of writing logic directly into the DTO that XRMLinq generates, consider creating a custom workflow activity that will fire when certain fields are updated. This forces your business logic to run even if those fields get updated somewhere else in the system (not through your custom DTO logic). It also gives you a nice queueing system and failback mechanism - if your custom workflow activity throws an exception, the workflow is "paused" until you fix the problem, at which point you can just resume the workflows that failed. This only works for business logic that can be run asynchronously obviously, but for synchronous logic I would still recommend looking at custom plugins before writing logic into the DTO.

Hope that helps!

Answer 3

Here are some good articles that detail a SOA architecture that has been trailed on projects of all sizes, the series is still been written, I believe it will be of use to you.

http://hubpages.com/hub/Building-Service-Orientated-Architecture