Unrelated data layer question.
-
Hi, I'm working on my second project at the moment that makes use of a 3-layer model. On my first project I had circular dependencies so that the data layer could hydrate and return a business object and take one as a parameter to save it back to the database. This worked fairly well although it was rather complicated. This time round I'm creating the data layer so that it takes individual values of a business object - strings, integers, etc - in order to save the objects, and it similarly returns the individual values through reference parameters to allow the business layer to hydrate objects. The second method seems to be making everything a lot simpler, however I've run into a little problem. With the first method when I wanted to get a collection of business objects the data layer would just create a collection and add each object into that before returning it. With the less coupled second method I cannot do this and must rely on the business layer to create a collection based on the values returned by the database. The problem I'm facing is that, without creating extra classes in the data layer just to store records from the database, I can't see a way of getting the data back to the business layer. I've read as much material on data layers as I can find, but none of it seems to cover this sort of thing. Has anyone got any ideas how to overcome this without creating extra classes which mimic those in the business layer? Regards, Matt
-
Hi, I'm working on my second project at the moment that makes use of a 3-layer model. On my first project I had circular dependencies so that the data layer could hydrate and return a business object and take one as a parameter to save it back to the database. This worked fairly well although it was rather complicated. This time round I'm creating the data layer so that it takes individual values of a business object - strings, integers, etc - in order to save the objects, and it similarly returns the individual values through reference parameters to allow the business layer to hydrate objects. The second method seems to be making everything a lot simpler, however I've run into a little problem. With the first method when I wanted to get a collection of business objects the data layer would just create a collection and add each object into that before returning it. With the less coupled second method I cannot do this and must rely on the business layer to create a collection based on the values returned by the database. The problem I'm facing is that, without creating extra classes in the data layer just to store records from the database, I can't see a way of getting the data back to the business layer. I've read as much material on data layers as I can find, but none of it seems to cover this sort of thing. Has anyone got any ideas how to overcome this without creating extra classes which mimic those in the business layer? Regards, Matt
CaptainMatt wrote:
The second method seems to be making everything a lot simpler, however I've run into a little problem.
Have you not recognized the seeming contradiction in your statement? Systems will have complexity if they do anything much at all, period. There is no getting away from it. You might find Grady Booch's Turing lecture[^] from last year interesting. All you have done is abandon an object oriented design for a procedural design. With that will come all the well known problems of a procedural solution. Your previous experience with complexity may seem like a cake walk by the time you are done. ;)
led mike
-
CaptainMatt wrote:
The second method seems to be making everything a lot simpler, however I've run into a little problem.
Have you not recognized the seeming contradiction in your statement? Systems will have complexity if they do anything much at all, period. There is no getting away from it. You might find Grady Booch's Turing lecture[^] from last year interesting. All you have done is abandon an object oriented design for a procedural design. With that will come all the well known problems of a procedural solution. Your previous experience with complexity may seem like a cake walk by the time you are done. ;)
led mike
Thanks for the reply, I realise that a completely object oriented design is most probably the correct way to go. However, half of the material I've read on creating data layers recommend using the procedural approach. I thought it might be a good idea to try it out and see how it goes, apparently not too well though. Since my first message I've made a start on re-writing the layer using objects. At the same time though I'm still interested in how the people who have taken this route have done this sort of thing or if extra data-only objects are used. Another reason my previous object oriented design was rather difficult to work with was that I initially followed an article that created persistence objects for every business object. A single persistence/database/storage object to persist the whole system makes things easier. Regards, Matt
-
Thanks for the reply, I realise that a completely object oriented design is most probably the correct way to go. However, half of the material I've read on creating data layers recommend using the procedural approach. I thought it might be a good idea to try it out and see how it goes, apparently not too well though. Since my first message I've made a start on re-writing the layer using objects. At the same time though I'm still interested in how the people who have taken this route have done this sort of thing or if extra data-only objects are used. Another reason my previous object oriented design was rather difficult to work with was that I initially followed an article that created persistence objects for every business object. A single persistence/database/storage object to persist the whole system makes things easier. Regards, Matt
While my experience in developing apps that have Datalayers is extensive, I have never extensively studied the problem domain. What I have picked up from direct experience and random discussions and articles is that the work and/or complexities associated with this domain have not been eliminated.
led mike
-
Thanks for the reply, I realise that a completely object oriented design is most probably the correct way to go. However, half of the material I've read on creating data layers recommend using the procedural approach. I thought it might be a good idea to try it out and see how it goes, apparently not too well though. Since my first message I've made a start on re-writing the layer using objects. At the same time though I'm still interested in how the people who have taken this route have done this sort of thing or if extra data-only objects are used. Another reason my previous object oriented design was rather difficult to work with was that I initially followed an article that created persistence objects for every business object. A single persistence/database/storage object to persist the whole system makes things easier. Regards, Matt
The common way people end up writing their DAL seems to be creating a procedural CRUD interface, which hits stored procedures in the DB ("for security" / "for performance"). This is generally done because people aren't leveraging the metadata features of the language. Also people like to use the Enterprise Data Access Block. So much so that they use it for general data access - when its really just a database abstraction kit - when they have no plans to ever switch database vendors. That ends up locking them out of a whole heap of cool tools :P In .Net at least, its possible to make a generic persistance layer that can operate on any business object which is correctly tagged up with persistance attributes. With a smattering of generics you can have a single persistence layer that isn't aware of your business objects. The way we do this is using reflection to read attributes that map the object model to the database schema. Reflection does have a small performance overhead - but you can make up for that by flexible queries - for example joining on referenced records in one round-trip. It also lets you provide generic FindByX routines, etc. So, yes, it is possible - and its a lot better than having to keep a whole bunch of structures that are only used for passing data between tiers maintained ;)
Mark Churchill Director Dunn & Churchill Free Download:
Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio. -
Hi, I'm working on my second project at the moment that makes use of a 3-layer model. On my first project I had circular dependencies so that the data layer could hydrate and return a business object and take one as a parameter to save it back to the database. This worked fairly well although it was rather complicated. This time round I'm creating the data layer so that it takes individual values of a business object - strings, integers, etc - in order to save the objects, and it similarly returns the individual values through reference parameters to allow the business layer to hydrate objects. The second method seems to be making everything a lot simpler, however I've run into a little problem. With the first method when I wanted to get a collection of business objects the data layer would just create a collection and add each object into that before returning it. With the less coupled second method I cannot do this and must rely on the business layer to create a collection based on the values returned by the database. The problem I'm facing is that, without creating extra classes in the data layer just to store records from the database, I can't see a way of getting the data back to the business layer. I've read as much material on data layers as I can find, but none of it seems to cover this sort of thing. Has anyone got any ideas how to overcome this without creating extra classes which mimic those in the business layer? Regards, Matt
Hi, I'm not quite sure I get what the problem is, but I'm attempting to give input based on the assumption that the problem is duplication of the same logic in the data access and busienss logic code. If so, a possible solution might be to derive the business classes from the data access classes. That is, make your data access classes so they contain all data storage for the type - as protected fields - and the knowledge of how to read/write those fields to and from persistent storage. Then derive business classes from these and publish those parts of the data that should be possible to directly manipulate from the outside using properties, adding validation logic as appropriate. (Some validation might be more appropriate in the DAL; there is a grey zone here. "Name cannot be more than 50 characters" might be considered data access logic or business logic; at first glance it only depends on the data store and as such could be considered DAL logic, but then again it might actually affect the layout of reports and what have you. In my view, it is simpler to keep all validation in one place, and if so it is undoubtedly the business layer that should do it.)
-
Thanks for the reply, I realise that a completely object oriented design is most probably the correct way to go. However, half of the material I've read on creating data layers recommend using the procedural approach. I thought it might be a good idea to try it out and see how it goes, apparently not too well though. Since my first message I've made a start on re-writing the layer using objects. At the same time though I'm still interested in how the people who have taken this route have done this sort of thing or if extra data-only objects are used. Another reason my previous object oriented design was rather difficult to work with was that I initially followed an article that created persistence objects for every business object. A single persistence/database/storage object to persist the whole system makes things easier. Regards, Matt
The problem with a completely object-oriented approach is that it doesn't work so well for a server scenario. Getting a bunch of data and instantiating a huge collection of instances is sort of useless if all you'll do with those instances is to serialize them and send off the data as, say, XML to a client somewhere, then discard all the objects. Likewise, deserializing a stream of (updated) data to a collection of objects and then use reflection or some other run-time schema mapping is rather useless. In a desktop scenario it sure is nice. Bind the grid to your objects and when the user changes something, modify the instances you've already loaded. When he saves, call Save(). It's great. But it doesn't work like that on a server, because you can't keep all those objects alive between the user reading the data and wanting to save. Which is why there is so much talk about "service" orientation. They say its "stateless objects" but without state it isn't really an object at all! Object-orientation is all about encapsulation. Service-orientation sacrifices that, because there's hardly any point protecting the state of an object that is used as little more than a serialization/deserializtion mechanism for SQL Server data...