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