views:

211

answers:

3

I have created an application (a web-based application) which now has a large number of associations. Simply put, an Account:

  • has many Users
  • has Settings
  • has many Projects

Similarly a Project:

  • has many Items

A User:

  • has many Tasks

And so on, with loads more associations. Nothing particularly unusual about that I hope. I chose to use NHibernate to give me a nice set of persistent classes with mappers defining all of the associations.

But is this approach right? On every request to the application the Account is loaded (because it is needed) and this then requests a large amount of data from the DB that is not required. Lazy loading is an option, but I don't know if my initial approach couldn't be better. All I want at that stage is the Account and associated Settings so should the mapping reflect this? Trouble is I want things like all the Projects for an Account at other points so I need the mappers to reflect all of the associations.

My concern is that lazy-loading may just be compensating for a bad initial architecture on my part. I am well aware that this may just be a result of my as-yet poor knowledge of the inner workings of NHibernate. As a result I'd be grateful for any suggestions on good practice.

A: 

It is generally good practise with NHibernate to enable lazy loading for most associations and objects by default unless you know you're always going to need the associated data. Then you can switch to eager loading selectively just for items where that is more efficient when you come to the optimisation stage.

Steve Willcock
A: 

Domain Driven Design has helped me a lot when understanding those kinds of situation. Association in DDD

The question you should ask yourself in your situation: Do you really need a bi-directional association - or might in some cases an uni-directional association be enough? And that decision is part of the architecture. So you were right. Lazy Loading is a big help, when choosing bi-directional associations by default. But it could be considered a design flaw.

Tobias Hertkorn
A: 

Well, in my oppinion, your architecture looks healthy. Associations are good.

Consider the alternatives:

  1. Less associations: Would lead to poor DB design
  2. Don't use an ORM: You would find yourself doing "lazy initialization"-kinda coding anyway

Everything looks fine, and lazy initialization is good :) - However, there's quite a few real-life-usage pitfalls:

  1. Don't close the session before using lazy-initialization stuff (would require that you "hacked" some useless reading statement on your association to force read it)
  2. With NHibernate, you need to do all DAL-activities with it in order to enable the level2 cache
  3. You'll prolly have some overhead (What if I don't wanna know the accountname, just the users in it)

This is how ORMs work. They have pro's (easier to develop, avoid a lot of boilerplate code) and con's (more overhead, less flexibility).

cwap