问题
I've hit a wall with trying to decouple NHibernate from my services layer. My architecture looks like this:
web -> services -> repositories -> nhibernate -> db
I want to be able to spawn nhibernate queries from my services layer and possibly my web layer without those layers knowing what orm they are dealing with. Currently, I have a find method on all of my repositories that takes in IList<object[]> criteria. This allows me to pass in a list of criteria such as new object() {"Username", usernameVariable}; from anywhere in my architecture. NHibernate takes this in and creates a new Criteria object and adds in the passed in criteria. This works fine for basic searches from my service layer, but I would like to have the ability to pass in a query object that my repository translates into an NHibernate Criteria.
Really, I would love to implement something like what is described in this question: Is there value in abstracting nhibernate criterion. I'm just not finding any good resources on how to implement something like this. Is the method described in that question a good approach? If so, could anyone provide some pointers on how to implement such a solution?
回答1:
abstracting away the ORM will:
- bring a lot of work of redefining it's API
- make it impossible to optimise/batch database access
- make it a lot harder to understand what queries are executed
- will lead to tons of SELECT N+1
and all for very little value: the vague option to exchange the ORM framework which will most probably have a lot of other problems
- missing features
- subtle difference in implementation
- learning curve
Update: experience
I was once involved in implementing a new provider of an existing DAL abstraction. It ended up performing badly, introduced a lot of bugs, Errorhandling was a mess and sometimes used stale data because the application assumed the default implementation. Reasons:
- Caching does not know context
- Cacheimlementation had different semantics
- batching APIs too different to be abstracted
- Errors are specific to implementation (e.g. FileNotFound -> FilesearchDialog is uselesss for a tcp/ip based databases)
- Error recovery is different (each implementation has it's own set of errors it can recover from)
- locking mechanism was different
- no consistent change event in SQL-Databases
- nested transactions
- default implementation bleeded in Model classes
- reimplementing all abstracted Queryies was a lot of work and introduced a lot of copy paste bugs
- querying without explicitly stating the order will return different ordered results in different implementations
It took a lot of refactoring of the application:
- strip out features only one implementation provides
- Cachemanagement for each implementation
- problem of Identity of Wrappers because of transient data
- implement Queries over two datastores very hard
Additional points:
- Migration of Data through the abstract DAL is slow as hell
- implementing yet another implementation will never occur because of the above stated problems it is too expensive (In the mentioned scenario we began to slowly reimplement the whole project)
- it was extreme difficult to implement the correct semantics of the DAL API because there is no context of use in the pure API
Porting (of business tasks) would have been a lot less painfull IMO as we did that for a few because of performance.
Update2: experience2: RoadBlocks while trying to port from NHibernate to EntityFramework (impl with NH but couldn't with EF 4 in reasonable time)
- nested Transactions
- Enum support
- references with compositeId (how to get rid of referenceIds)
- references in Components
- read batching (Futures) which is handy for page + count in one go
- mapping CultureInfo (IUserType support)
回答2:
Thank you for the responses! I understand what you are saying, but these answers do not solve my problem. Because of the state of the system I'm writing, I am unable to change my architecture. Instead, I am just going to keep all of my sql/hql/criteria api queries inside of the repository layer instead of trying to expose some sort of a complex query class to my services. This approach should work just fine. For my next architectural approach though, I will consider the points made in the other answers.
来源：https://stackoverflow.com/questions/12903560/how-can-i-solve-this-nhibernate-querying-in-an-n-tier-architecture