Master / Detail Datasource design quesiton
-
Given the example of an Invoice, where you have 2 distinct areas; a header and details. Can someone shed some light on how I should design my classes to support this ? Here is what I do now: 1) create a base class called, InvDetails 2) create a factory class call, InvDetailsFactory. (The factory will be responsible for reading and updating the Invoice details) 3) create a base class called, InvHeader 4) create a factory class called InvHeaderFactory (same idea as above) Should I create a single class, Invoice, which has 2 components: Header and a collection of Details ? Your input is welcome and appreciated. :rose:
-
Given the example of an Invoice, where you have 2 distinct areas; a header and details. Can someone shed some light on how I should design my classes to support this ? Here is what I do now: 1) create a base class called, InvDetails 2) create a factory class call, InvDetailsFactory. (The factory will be responsible for reading and updating the Invoice details) 3) create a base class called, InvHeader 4) create a factory class called InvHeaderFactory (same idea as above) Should I create a single class, Invoice, which has 2 components: Header and a collection of Details ? Your input is welcome and appreciated. :rose:
To be specific an invoice is a 'report'. Where a report is a static presentation of existing data in a preset form. A better starting point is a order entry screen which would have a create customer screen and a order entry screen. The first lets the operator enter name, address, billing address, etc. From this you have a data model object called 'customer' The second lets an operator pick a customer (already created) and the add order items for the customer. From this you have data model objects for 'order' and 'item' (or call it 'order item' if you prefer.) For an invoice you would then start with a order number. That allows you to get the order and from that you get the items and customer. You also need a 'form'. The form describes the layout of the invoice itself. For example the name and address could be on the left with the order number on the right.
-
To be specific an invoice is a 'report'. Where a report is a static presentation of existing data in a preset form. A better starting point is a order entry screen which would have a create customer screen and a order entry screen. The first lets the operator enter name, address, billing address, etc. From this you have a data model object called 'customer' The second lets an operator pick a customer (already created) and the add order items for the customer. From this you have data model objects for 'order' and 'item' (or call it 'order item' if you prefer.) For an invoice you would then start with a order number. That allows you to get the order and from that you get the items and customer. You also need a 'form'. The form describes the layout of the invoice itself. For example the name and address could be on the left with the order number on the right.
My bad for using the term, Invoice. Maybe it was confusing. Let's go with the concept of an "Order Entry" screen (web page). My question still stands: "Should I create a single class, which has 2 components; Header and a collection of Details?" Or Should I just create 2 separate classes, one that stores and manipulates the Header data while the other represents the details ? Just looking for some suggestions / ideas.
-
My bad for using the term, Invoice. Maybe it was confusing. Let's go with the concept of an "Order Entry" screen (web page). My question still stands: "Should I create a single class, which has 2 components; Header and a collection of Details?" Or Should I just create 2 separate classes, one that stores and manipulates the Header data while the other represents the details ? Just looking for some suggestions / ideas.
My previous example described it specifically in terms of an order entry screen. Precluding the orders themselves, other informatin on the screen would come from 'order', 'customer' and/or inventory (where the data model for that has not yet been defined.)
-
Given the example of an Invoice, where you have 2 distinct areas; a header and details. Can someone shed some light on how I should design my classes to support this ? Here is what I do now: 1) create a base class called, InvDetails 2) create a factory class call, InvDetailsFactory. (The factory will be responsible for reading and updating the Invoice details) 3) create a base class called, InvHeader 4) create a factory class called InvHeaderFactory (same idea as above) Should I create a single class, Invoice, which has 2 components: Header and a collection of Details ? Your input is welcome and appreciated. :rose:
Can the details exist outside of the master? If not then it is an internal class. I would design it having a
Masterwith the overriding details and a list ofDetailobjects. I'm not convinced you'll need a specialised factory for creating these items, they have relatively simple creation interfaces. I would however consider how theMasterwill createDetailobjects
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
Can the details exist outside of the master? If not then it is an internal class. I would design it having a
Masterwith the overriding details and a list ofDetailobjects. I'm not convinced you'll need a specialised factory for creating these items, they have relatively simple creation interfaces. I would however consider how theMasterwill createDetailobjects
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
You have answered my question. I'm still working on other aspects of the application, so I haven't implemented my Master / Detail business objects yet. Thanks again.
-
My bad for using the term, Invoice. Maybe it was confusing. Let's go with the concept of an "Order Entry" screen (web page). My question still stands: "Should I create a single class, which has 2 components; Header and a collection of Details?" Or Should I just create 2 separate classes, one that stores and manipulates the Header data while the other represents the details ? Just looking for some suggestions / ideas.
I build my classes to reflect the data structure
Customermay have a collection ofOrder(s)Ordermay have a collection ofOrderItem(s)AnInvoicewill have aCustomerAninvoicewill have a collection ofOrderItem(s)Eachcode blockis a table and also a classNever underestimate the power of human stupidity RAH
-
I build my classes to reflect the data structure
Customermay have a collection ofOrder(s)Ordermay have a collection ofOrderItem(s)AnInvoicewill have aCustomerAninvoicewill have a collection ofOrderItem(s)Eachcode blockis a table and also a classNever underestimate the power of human stupidity RAH