Building Complicated Objects in an N-tier application...
-
Hi All, In my 3 tier application, I have a business object called a "machine", which has various simple properties such as Name and Asset Number. It also has properties consisting of other objects such as ListMeterReadings and Model ModelInfo In order to construct the "machine" object, my BLL dials into the DAL (and thence the Database), which then returns a Machine. Subsequently, the BLL dials back into the DAL to fetch the list of Meters and then adds these to the Machine's MeterReadings property, and then the BLL dials into the DAL once more to fetch a Model object and applies this to the Machine's ModelInfo property. In effect, what I have here is the "parent" Machine object being constructed in the DAL, whilst the BLL then manages the addition of the "child" objects. I'm not 100%, but I think I'm going about this the wrong way, as it seems quite messy - and I can certainly see that a more complicated object (with more sub objects-as-properties) could become quite unwieldy and difficult to debug. Could anyone recommend a better method of acheiving this? For example, would it be better to make each Business Object (in my case the parent "Machine") responsble for all of its sub-objects? Cheers, Martin.
-
Hi All, In my 3 tier application, I have a business object called a "machine", which has various simple properties such as Name and Asset Number. It also has properties consisting of other objects such as ListMeterReadings and Model ModelInfo In order to construct the "machine" object, my BLL dials into the DAL (and thence the Database), which then returns a Machine. Subsequently, the BLL dials back into the DAL to fetch the list of Meters and then adds these to the Machine's MeterReadings property, and then the BLL dials into the DAL once more to fetch a Model object and applies this to the Machine's ModelInfo property. In effect, what I have here is the "parent" Machine object being constructed in the DAL, whilst the BLL then manages the addition of the "child" objects. I'm not 100%, but I think I'm going about this the wrong way, as it seems quite messy - and I can certainly see that a more complicated object (with more sub objects-as-properties) could become quite unwieldy and difficult to debug. Could anyone recommend a better method of acheiving this? For example, would it be better to make each Business Object (in my case the parent "Machine") responsble for all of its sub-objects? Cheers, Martin.
It is difficult to convey how, over the years, you easily perceive the structure your application requires. But it's all by rules/observations. Strive to conceive of the structure you need to build by perceiving where the best place is for each thing it needs to do. In effect, objects or classes design themselves if you let the job dictate the object. In the end, there is no such thing as a "bad" class, simply because the class involves many objects or properties. Neither is there a real metric you should follow -- how big should a class be, or what are too many instance methods or members for instance? The size of the best defined objects is predicated by doing the job the best way it can be done. A lot of your work then is refining classes. You see that you will benefit if you split your large object up into smaller objects; or you see that you accomplish an important goal better by incorporating a further method. Always however, the job dictates class design. Concentrate on doing the job(s) the best they can be done, and you will build the best classes.