CSLA .NET

Let me start off by saying that I know this is not a CSLA question, but this is the best group of Business Object knowledgeable people I know.

Also, I apologize if this topic has already been covered someplace I haven’t found.

I am looking at building a n-tier architecture for my company.  The problem is that our main business accounts are data heavy.  Plus we have a web application that interacts with all the aspects of the account.  As a web application it asks for the same information over and over when pages are reposted.  I feel like this is a waste because often times, only parts of the data are actually needed.  The solution that is currently in place utilizes a bunch of different versions of the account depending on the purpose. 

My idea is to create an account entity but have many sub-classes to it.  For instance, I could have the Configuration class, Notes class, and the Documents class, etc.  Configuration would be a single private member, but Notes and Documents would be collections private members.  I would leave Configuration null until someone tried to access one of the properties of it.  Then the public property code would execute what was needed to retrieve that class’s information.  This would result in a lighter class because most of the class would be null, unless it is requested.  In addition, if I know I am going to be dealing with a group of configurations, I can deal with them alone and skip loading the whole client.

Anyone have any opinions? Ideas?

Thanks

It sounds to me like you are on the right track on at least two things you are doing. First implementing a "bunch of different versions of the account depending on the purpose" seems to be exactly what the CSLA veterans here advocate -- tailoring objects to the specific use case, with it being OK to have multiple objects that map to the same database tables.

The second technique you are using -- delaying loading of an object until it is used -- is often referred to as "lazy loading" and is one of my personal favorite techniques. You can combine this with tagging the same fields as [Nonserialized] where appropriate so that you avoid transmitting them over the data portal. This is reasonable technique for read-only child collections but not a good idea for something that can be edited.

It would seem to me that your Account object has numerous behaviours.  With behavioural modelling you ideally want to break it down so that each object has only one behaviour.  This may lead to you having a number of Account objects that each have their own individual behaviour or purpose, and will therefore map easily to any use cases you may have. What stumps a lot of people is that this is likely to involve "duplicate" code, although this isn't strictly true.  It is likely that a number of objects share the same properties and retrieve the same data, but they do so for different reasons (behaviours).

So with that in mind think about the parts of your account object and see if you can break it down.  As a start point you could have Account, AccountInfo (lightweight & read-only), and AccountList (read-only list of AccountInfo).

From what you've said, I think you can seperate a lot of functionality from the "Account" object.  Configuration, Notes, and Documentation could be made into objects in their own right.  You still could provide methods in an Account class such as public AccountConfiguration GetAccountConfiguration().

Also consider the following:

AccountNotesList : List<AccountNote>

AccountDocumentList : List<AccountDocument>

Hopefully by breaking these different objects away from a huge "Account" object will keep your code far more maintainable. Also consider the different behaviours of the "Account" object and see if you can break it up, such as Purpose1Account or Purpose2Account.