Like to pose this question to the public. Say you have a class (employee) that has hundreds of fields (properties). Most of these properties are rarely used or updated but are still necessary. Is it better to
1) Create two distinct employee classes. BaseEmployee, and Employee with the larger (BaseEmployee) inheriting the dynamic fields from the baseEmployee class.
2) Seperate the large entity into an Employee class that contains a lazy load collection of atypical properties. And load these when demanded??
Or any other solutions to this question???
Will definitely need access to all employee properties at time of insertion.
Thanks
Don
Thoughts are very much appreciated!
Option #1 has been discussed here before as it seems to be the OO approach to the problem. Although I think composition would be more appropriate than inheritance. The main problem there seems to be working out the data access plumbing given that one of the classes would be loadable both independently and as part of the other class.
A third option would be to make the business object infrasture more robust/complex such that a particular BO would have "modes" that would control what data was loaded and which fields were not only loaded but also valid to get/set. In my consideration the appeal of having only one class containing all the code is buried beneath a) the violation of the "one responsibility" principle and b) the difficulty in using the class since there wouldn't be any good way of discerning which public properties were valid for the mode you planned to load.
Whenever a class has hundreds of fields, it usually means it is taking on too much responsibility. You might want to think about breaking up that huge class into smaller classes if it makes sense to do so. I personally can’t imagine why an employee class would have hundreds of fields.
I had such a problem in a project: the users needed to allow multiple means of processing a manufactured component. They needed a boolean field for each option (about 120 possibilities) and none of them could be disabled, just ordered into a sequence.
I ended up using bit wise processing on a muliti-bit field. It worked, but the public property code is just monstrous. Not a design issue either... at least this time. ;-]
_E
ajj3085:
Well, I think the question to be asked is, does the use case actually have the user modifying most of those properties all at the same time. In all likely hood, you'd think that for any given operation, the user would only be modifying a subset of those properties... but maybe there is a real business need where all of them need to be modified at once.
That's true, but you're still left with the question of how to code the answer into classes. I think having 20 different Employee objects becomes a nightmare in itself both in using them and in the property creep that would undoubtedly happen between them.
I think it's useful to think of having a couple of (or maybe one) facade Employee classes that includes all of those details via composition. One aspect of that is to consider using some lazy loading on those aggregated objects such that the facade object only gets as "heavy" as necessary.
It would be interesting to develop a Patterns & Practices document for solving these kinds of problems with CSLA wouldn't it? Part of the value of CSLA in selling it to executives is Rocky's stature (not physically, although he is a tall one) and this community. Having recommended standard guidelines for its use would increase that argument exponentially says me. :)
I will assume that your employee class needs hundreds of properties. If you are concerned about retrieving all of that data then you will need to lazy load the properties that are not used often. I am not sure if a façade is appropriate if you have one large employee class. A façade is used to make a subsystem easier to use. If you only have one large employee class, it would not make sense to create a façade. However, if you decided to break your employee class into many classes, you could use a façade to make the subsystem easier.
Copyright (c) Marimer LLC