Architecture 101....

daniel byrne

Hi everyone, I am a software developer that is looking to improve the way I design my classes... In my classes usually I have a constructor where an ID or some identifier is passed in, the constructor then goes off to the database and populates that objects member variables. A 'save' of an object would find the relevant record in the database and overwrite it's data. What's all this I've been hearing about a separate data access layer - how would you go about implementing one. I have been thinking for a while that this is a bad design (should you get the data before you create the instance of the class and pass this to the constructor?) and if this is the case, wouldn't you just be moving the SQL into the UI or the calling method... Does my way of doing this look as messy as I feel like it does; and is there any way around having to code each and every member variable into the class, and corresponding GET/SET methods? It feels like each class I design takes at least an hour each to hand code all the even generic getters and setters never mind the logic of the actual class itself and then is full of messy SQL Select and Update statements. I guess I'm after a pointer to an 'architecture 101' type tutorial :) Thanks in advance for any pointers/ideas.

led mike

daniel.byrne wrote:

What's all this I've been hearing about a separate data access layer - how would you go about implementing one.

http://en.wikipedia.org/wiki/Data_access_layer[^] There is also this thing called Google that will find information for you. For example to find that link above I entered the search phrase: Wikipedia data access layer Other things you might be interested in: http://www.google.com/search?hl=en&q=wikipedia+Software+Design+Patterns&btnG=Search[^] http://c2.com/cgi/wiki[^]

led mike

daniel byrne

Thanks for your reply, however I usually do Google, and have only come to a forum on this one occasion to engage in a discussion rather than look at dry documents.

led mike

daniel.byrne wrote:

rather than look at dry documents.

Dry documents published by well established leaders in the industry are far more valuable than, never mind. Well that just proves you have no experience on c2.com since there are some extensive discussions on that wiki. Ok, I know return you to your regularly scheduled program of burying your head in the sand.

led mike

daniel byrne

First of all, thank you for your link. It has been bookmarked and I am going to give it a read. I'm sure you have your uses here but being personable is obviously not a strong point of yours ledmike. If you are trying to be helpful or teach someone then being a condescending troll is not the best way of going about it. However, if your intention IS to be a troll, then well done friend. If you had considered this topic to be 'beneath you' then nobody was forcing you to post your stereotypical RTFM comment. Is the rest of this forum so unfriendly to people that are just trying to learn? I won't be sticking around to find out.

Scott Dorman

For better or worse that is simply Mike's personality (at least here on CP) so take it with a grain of salt. He actually seems to be in pretty rare form today.

Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

[Forum Guidelines] [Articles] [Blog]

led mike

daniel.byrne wrote:

I'm sure you have your uses here but being personable is obviously not a strong point of yours ledmike.

there is nothing in my first reply that is not personable. You chose to respond to my help by calling the links I provided "dry documents" when clearly you could benefit from reading them. There are many people that come to code project that truly desire to improve their skills and welcome any assistance. I have no patience for the others. You can lead a horse to water but you can't make him fish. Good luck.

led mike

Pete OHanlon

daniel.byrne wrote:

I have been thinking for a while that this is a bad design (should you get the data before you create the instance of the class and pass this to the constructor?) and if this is the case, wouldn't you just be moving the SQL into the UI or the calling method...

The whole point of a DAL is to abstract the "messy" part of retrieving data away from the UI which should neither care nor know how the data was retrieved or stored in the first place. That's not the job of the UI. The DAL is the place to manage the whole CRUD operations. A common technique for data access is to provide a static Fill method that returns you an instantiated version of your model. This method could (for instance) use a DataRow to populate it's own information, so you'd have a controller class which retrieved a set of data (in the form of a DataReader) and then populate a collection of your model simply by "Filling" each item in the collection. BTW - there are some excellent code generators that automate the tedious process of getting the data out of the database and into your model.

Deja View - the feeling that you've seen this post before.

My blog | My articles

jtvberg

"there is nothing in my first reply that is not personable." Yeah, "There is also this thing called Google that will find information for you." Real personable.