decoupling business and database?
-
hi , I'm a pretty simple self taught developer. I did do some reading on business objects , 3-tiered apps etc and i just got myself a book on OOAD. But i'm still not very clear about decoupling the data layer and the business layer. In my DB i have 2 tables -Rooms and Persons: Rooms: RoomID Cost PersonID Persons: PersonID Name LastName Age... ... So , my business objects[Room , Person] are pretty much a class with properties corresponding the columns in the table. I need to have a cache of all Persons and all Rooms , so dont keep accessing the DB all the time. Should my data layer do this: (Should the DataLayer know the existence of the business class?? List GetPersons() { //open a connection...(sql servr 05) //get data //iterate through all the persons .. lstTemp.Add(new Person**(strName , strLastName , iAge...)); //end iterate return lstTemp; } Also , i did say the classes are just like the columns. Persons.PersonID & Rooms.PersonID have a relatioship in the DB the Person class has: +int PersonID +string name ... And Room : +int RoomID +int cost ... (They hold IDs just like the DB) After my app loads , i have a seperate List<> of Persons and Rooms , and if i need to know what Person is in a particular room , like DB access , i have to Traverse the Persons list in memory to find the right Room.PersonID This is not correct right? Is there some article book or anything that would educate me on how to do this right!??? Thanks so much Gideon
-
hi , I'm a pretty simple self taught developer. I did do some reading on business objects , 3-tiered apps etc and i just got myself a book on OOAD. But i'm still not very clear about decoupling the data layer and the business layer. In my DB i have 2 tables -Rooms and Persons: Rooms: RoomID Cost PersonID Persons: PersonID Name LastName Age... ... So , my business objects[Room , Person] are pretty much a class with properties corresponding the columns in the table. I need to have a cache of all Persons and all Rooms , so dont keep accessing the DB all the time. Should my data layer do this: (Should the DataLayer know the existence of the business class?? List GetPersons() { //open a connection...(sql servr 05) //get data //iterate through all the persons .. lstTemp.Add(new Person**(strName , strLastName , iAge...)); //end iterate return lstTemp; } Also , i did say the classes are just like the columns. Persons.PersonID & Rooms.PersonID have a relatioship in the DB the Person class has: +int PersonID +string name ... And Room : +int RoomID +int cost ... (They hold IDs just like the DB) After my app loads , i have a seperate List<> of Persons and Rooms , and if i need to know what Person is in a particular room , like DB access , i have to Traverse the Persons list in memory to find the right Room.PersonID This is not correct right? Is there some article book or anything that would educate me on how to do this right!??? Thanks so much Gideon
I believe the problem you are trying to solve is how to perform the Object relational mapping. This is a common enough problem that there are packages like NHibernate (Quick start guide) that automate the task for you.
-
I believe the problem you are trying to solve is how to perform the Object relational mapping. This is a common enough problem that there are packages like NHibernate (Quick start guide) that automate the task for you.
hi , thanks for replying. Acutally , i've been told to use an O/RM solution before.(checked nHib) But i already wrote a datalayer(and spent quite some time on it). So i'm a little stubborn about that. Acutally i've described a simplified version of my framework. I'm just a little confused about how i should store a cache of my objects and access them real quick without having my custom controls need pointers via a property to a List<> of Persons , Rooms , Reservations......etc I read some more on DALs , i've seen examples with one object holding referenced to many child objs like a one-to-many relation. But some of my relations are a little more complex. I have class Customer: //just a way to group many Persons, could call it Group. +Name +List<> Persons But Reservation has +StartDate +EndDate +PersonID //if i had reference to a Person obj here , how would i get the parent customer? Should Each person have a .Parent property!?? Thanks so much Gideon
-
hi , I'm a pretty simple self taught developer. I did do some reading on business objects , 3-tiered apps etc and i just got myself a book on OOAD. But i'm still not very clear about decoupling the data layer and the business layer. In my DB i have 2 tables -Rooms and Persons: Rooms: RoomID Cost PersonID Persons: PersonID Name LastName Age... ... So , my business objects[Room , Person] are pretty much a class with properties corresponding the columns in the table. I need to have a cache of all Persons and all Rooms , so dont keep accessing the DB all the time. Should my data layer do this: (Should the DataLayer know the existence of the business class?? List GetPersons() { //open a connection...(sql servr 05) //get data //iterate through all the persons .. lstTemp.Add(new Person**(strName , strLastName , iAge...)); //end iterate return lstTemp; } Also , i did say the classes are just like the columns. Persons.PersonID & Rooms.PersonID have a relatioship in the DB the Person class has: +int PersonID +string name ... And Room : +int RoomID +int cost ... (They hold IDs just like the DB) After my app loads , i have a seperate List<> of Persons and Rooms , and if i need to know what Person is in a particular room , like DB access , i have to Traverse the Persons list in memory to find the right Room.PersonID This is not correct right? Is there some article book or anything that would educate me on how to do this right!??? Thanks so much Gideon
Well, your case might not warrant a seperate layer. For one though, if you want your app to scale well, then holding all of the data in memory might not be reasonable. Say this is a website you're starting for a new business. The worst thing that can happen is that it succeeds, and you have 20,000 records to hold in memory. The main purpose of seperating out the data layer is if you're building an app that needs to target multiple data sources. If you will only ever need just the one source, then you might not need to worry about it. I would recommend though, that you put the data access code in a seperate file. So that your business objects can stay slim for serialization purposes. Sounds like your situation doesn't warrant worrying too much about it. But as it grows and if you plan to target more than one database (say its a reservation system you'll sell to mutliple clients) then you might benefit from it.
This statement was never false.