I have a couple of design issues
-
In the past I have used datatables as my data "entity". So if I wanted a list of rooms for a house I have a stored proc for GetRoomsForHouse(HouseID) and this would reside in the Rooms class. Now with List<> I am moving to lists of objects as my data "entity". My current structure (LoadObject) is up the FK path ie Fitting inherits from Room from House from Street etc. So getting a fitting (stool) will get 4 records from the database to load the ingeritance tree, this is fine and works well if there you are working with 1 stool. Now I want all the fittings in Room101, this potentially generates 4 x #n fittings calls to the database to load the List. This is still reasonable but when I want a list of all fittings in 60 storey tower block it gets a little overwhelming. In the past I would simply have a proc to get all fittings by a number of different criteria and use the datatable to load the display controls. So I have a number of option to follow: 1. Continue with the proc to datatable - this precludes using a List<> to populate data list controls 2. Use the LoadObject method and wear the database calls - worst case and will not be implemented X| 3. Use a proc to get the data IE Fittings RoomName,HouseNo,StreeName etc and create a class to service a List with the results from the proc. 4. Split my design of an object to display/process where display gets only the data used to load into list controls. The process object would be a full inheritance tree of a single object (Fitting). I want to use 3 but it means there will be a plethora of classes in the app to support display. 4 may be the better option as it standatdises on the object rather than the proc. The amount of code is not an issue as I will use my code generator to build it all. 2nd issue When dealing with lists of objects should the list reside in the parent or the child eg: Room has a List and while the select for the List is on Fittings the List is on Room - Parent has the list. Fittings has a List for a Room and retains the List on the Fittings object - Child has the list.
Never underestimate the power of human stupidity RAH
-
In the past I have used datatables as my data "entity". So if I wanted a list of rooms for a house I have a stored proc for GetRoomsForHouse(HouseID) and this would reside in the Rooms class. Now with List<> I am moving to lists of objects as my data "entity". My current structure (LoadObject) is up the FK path ie Fitting inherits from Room from House from Street etc. So getting a fitting (stool) will get 4 records from the database to load the ingeritance tree, this is fine and works well if there you are working with 1 stool. Now I want all the fittings in Room101, this potentially generates 4 x #n fittings calls to the database to load the List. This is still reasonable but when I want a list of all fittings in 60 storey tower block it gets a little overwhelming. In the past I would simply have a proc to get all fittings by a number of different criteria and use the datatable to load the display controls. So I have a number of option to follow: 1. Continue with the proc to datatable - this precludes using a List<> to populate data list controls 2. Use the LoadObject method and wear the database calls - worst case and will not be implemented X| 3. Use a proc to get the data IE Fittings RoomName,HouseNo,StreeName etc and create a class to service a List with the results from the proc. 4. Split my design of an object to display/process where display gets only the data used to load into list controls. The process object would be a full inheritance tree of a single object (Fitting). I want to use 3 but it means there will be a plethora of classes in the app to support display. 4 may be the better option as it standatdises on the object rather than the proc. The amount of code is not an issue as I will use my code generator to build it all. 2nd issue When dealing with lists of objects should the list reside in the parent or the child eg: Room has a List and while the select for the List is on Fittings the List is on Room - Parent has the list. Fittings has a List for a Room and retains the List on the Fittings object - Child has the list.
Never underestimate the power of human stupidity RAH
I don't understand your question. Is your question basically that you know how to load one object from the database but loading multiple objects seamlessly from the database (or any storage) you are having trouble with?
CodingYoshi Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
-
I don't understand your question. Is your question basically that you know how to load one object from the database but loading multiple objects seamlessly from the database (or any storage) you are having trouble with?
CodingYoshi Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
I thought I had wasted my time with this question. No I have no problem managing the data it is the design I am tossing around. When dealing with a list of something do I create the list in the something class or in the parent class. 2 classes, Department and staff. I now want a list of staff for the department. Is the best design I am after. Departmant List of staff for department(this.DepatmentID) Staff Get for Department(DepartmentID) Or both, hah thats probably the right way. Staff gets the list for a department because it is a list of staff and department calls the same method on staff to get the list of staff for itself. The problem is I use stored procs ALL the time so there would be a proc out there called StaffGetForDept(@DeptID) and deciding on the owner class for the proc is sometime an issue.
Never underestimate the power of human stupidity RAH
-
I thought I had wasted my time with this question. No I have no problem managing the data it is the design I am tossing around. When dealing with a list of something do I create the list in the something class or in the parent class. 2 classes, Department and staff. I now want a list of staff for the department. Is the best design I am after. Departmant List of staff for department(this.DepatmentID) Staff Get for Department(DepartmentID) Or both, hah thats probably the right way. Staff gets the list for a department because it is a list of staff and department calls the same method on staff to get the list of staff for itself. The problem is I use stored procs ALL the time so there would be a proc out there called StaffGetForDept(@DeptID) and deciding on the owner class for the proc is sometime an issue.
Never underestimate the power of human stupidity RAH
I don't like the idea of asking the Staff object to return a list of Staff objects. A staff should have methods and properties for a Staff but not a list of Staff. I would take one of the collection classes (if using .NET or something similar if using else) and extend it like below: public class StaffCollection : List<Staff> { private Department _department; // Inject the object with the department at construction // Now this staff collection realizes its department public StaffCollection(Department dept) { this._department = dept; } public void Load() { // Load this from the database. I will create a DAL and pass a reference of this to it so it can load it for me. } // You can put many other methods--based on your requirements--here. For example, find all employees who earn more than 100K and it will return a bunch of employees who wear pink shirts and have spiked up hair } Here is the department class public class department { // put everything for department here: email, name etc. private StaffCollection _staffs; public Department() { this._staff = new StaffCollection(this); } public void LoadStaff() { // You can check first if already loaded or just reload everytime this._staff.Load(); } } You will still need a Staff class and might need a DepartmentCollection class.
CodingYoshi Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
-
I don't like the idea of asking the Staff object to return a list of Staff objects. A staff should have methods and properties for a Staff but not a list of Staff. I would take one of the collection classes (if using .NET or something similar if using else) and extend it like below: public class StaffCollection : List<Staff> { private Department _department; // Inject the object with the department at construction // Now this staff collection realizes its department public StaffCollection(Department dept) { this._department = dept; } public void Load() { // Load this from the database. I will create a DAL and pass a reference of this to it so it can load it for me. } // You can put many other methods--based on your requirements--here. For example, find all employees who earn more than 100K and it will return a bunch of employees who wear pink shirts and have spiked up hair } Here is the department class public class department { // put everything for department here: email, name etc. private StaffCollection _staffs; public Department() { this._staff = new StaffCollection(this); } public void LoadStaff() { // You can check first if already loaded or just reload everytime this._staff.Load(); } } You will still need a Staff class and might need a DepartmentCollection class.
CodingYoshi Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
CodingYoshi wrote:
I would take one of the collection classes
Now that makes sense, I have no collection classes in my design, all the lists (I usually use datatables) come from the single class, this is b/c of my reliance on datatables (and recordsets of course) in the past.
Never underestimate the power of human stupidity RAH