NHibernate, n-tier solution + consultation request

Question

I have a chance to develop a mildly complex project and study the various approaches that I can use to solve this project. I would usually work with the traditional 3-tier approach, but after spending some time on the various options, I have a suspicion that some kind of ORM might be better, and I am considering nHibernate. However, I am looking for some recommendations for implementing nHibernate and, more specifically, how I will structure BL and DAL in combination with nHibernate.

With nHibernate, I would create my objects (or DTO?) And use the nHibernate methods for my CRUD interactions in my DAL. But what I can’t make out is that the objects defined in the DAL are probably better located inside the BL, i.e. Where validation and other things can be done easily, and I just use the DAL from various ObjectFactory / ObjectRepositories. Unfortunately, through many articles that I read, this is not mentioned and is not bypassed, and I'm a little confused.

What is the most acceptable or easier way to implement when using nHibernate on a three-tier system? Alternatively, what is the usual method of exposing objects through the business layer from the data layer to the presentation?

Answer 1

My personal experience with nHibernate made me decide that the level of data access was becoming so subtle that it never made any sense to separate it from the business logic. Most of your data access code is already split into xml files (or various other distinguishing methods, such as Fluent nHibernate), and since connections are handled almost transparently, your queries using criteria objects rarely have more than a few lines.

Answer 2

I suspect you were overdoing it. nHibernate is basically a fairly simple tool; it basically controls the serialization of your records in your database to and from similarly structured objects in your data model. This is basically it. Nothing says that you cannot encapsulate Hibernate objects in Business Layer objects for validation; it's fine. But understand that validation and serialization operations are fundamentally different; Hibernate manages the serialization component and does it pretty well. You can consider Hibernate serialization objects to be efficient "atomic" ones.

Basically, you want: nHibernate - your level of data access. (Of course, you can use other data access methods at your data access level, but if you intend to use Hibernate, you must adhere to the basic design of Hibernate data, that is, simple objects that perform relatively direct mapping of the record for the object.) If for your design requires that you use a different design (deeply arranged objects that depend on many overlapping tables) that do not display well in Hibernate, you may have to abandon the use of Hibernate; otherwise, just go with the simple POCO approach, as nHibernate implies.

Answer 3

I'm a fan of architecture resolution, but this is what my starting architecture will look like on a typical npier asp.net mvc project if I started it today with NHibernate.

Firstly, I will try to save as much domain code as possible outside the controller. Therefore, I would create a service level / facade over the business layer that the controller (or code behind) is accessing. I would divide my objects into two types: 1) objects with business behavior that are used on the recording side, and 2) ViewModel / DTO objects that are used to display data and enter initial data input. These DTOs would have all the specific problems, such as simple validation attributes, etc. DTOs could have their own NHibernate mappings, or they could be designed using the NHibernate AliasToBean function. They will be mapped to business objects as soon as they pass the controller in operations.

As for the level of data access, I would probably use NHibernate directly at the service level. I would not use the repository template if I did not know that I should be able to change ORM. NHibernate is already an abstraction of perseverance. Putting a repository above it forces you to abandon many functions.

Answer 4

I have NHibernate-based applications in production, and although it is better than most DALs, I am in a situation where I never recommend anyone use NHibernate. The sophistication that is required to work with a session to make any advanced application is simply absurd. For simple applications, NHibernate is very trivial for an enterprise application, there is no complexity in the diagrams.

At this point, I came to the decision to allow access to data with 3 different options depending on the application, using a document database (in particular, Raven at present) for a full-scale application, for medium volumes of data access using LinqToSql and for trivial access I really use raw ADO.NET connections with great success.

For reference, these statements after I spent 2 years developing using NHibernate, and every time I ever felt like I fully understood NHibernate, I came across some kind of new restriction or giant monkey key, which i need to do deal with. It also led me to realize that I started developing applications with respect to NHibernate, which is one of my main reasons for using ORM so that the design of applications is not database driven.

Not having to deal with session management with NHibernate complexity, I was one of the biggest moments to upgrade to RavenDB. With Raven, you need very little session management, unless you are performing extreme performance optimizations or working with batch actions.

Answer 5

My 02 cents (as there are no answers to all answers):

DAL should ONLY be responsible for finding and storing data.

you may have a library containing your model (objects) that are filled with DAL but are loosely coupled (theoretically you should be able to write a new DAL using other technologies and connect it instead of NHIBERNATE, even if you are not going to)

to talk with the client ↔ BL, I would seriously advise views / dto to avoid pairing the model with the client (trust, I .. I clean the application like this and this is hell)

anyway .. I'm talking about the situation that we are using here, which follows this structure:

client (winforms and web) ↔ View / Presenter ↔ WCF services using messages ↔ BL ↔ DAL