itsraja wrote:Depends on your requirements. My guess is an invoice is one to one to customer and one to many to product. Store the former as a reference to the object itself and the latter to a collection of products.
I'm having an Invoice object which consists of customer id and product ids. Customer and Product are separate classes.
I'm implementing CRUD for this Invoice.
Should the Invoice object have object references for both participating customer and product objects.
I'd like to know if there is a common method of implementing CRUD operations*(with DB backend)* that involve the above mentioned object relations.Lookup Java Persistence API.
I'd like to have an article that best describes a simple design (may be with Factory pattern-am learning it) with mysql db backend or any db for this problem. Also I got to create Reports on Invoices, products, etc.See the Data Access Object pattern. JPA will handle the rest. You may want to create a front-end service facade.
Big Thanks.You are welcome.
itsraja wrote:CRUD refers to supporting existing tables. If you have additional business functionality it is no longer really CRUD.
I'd like to know if there is a common method of implementing CRUD operations*(with DB backend)* that involve the above mentioned object relations.
jschell wrote:what I'm looking for is to learn best ways to design complex object interactions.
If you have additional business functionality it is no longer really CRUD.
Do you have existing tables?yes i have existing tables and additional functionality. I'll look out JPA and DAO.
itsraja wrote:[Extension Interface|http://www.laputan.org/pub/sag/extension-interface.pdf|description] pattern hm?
...what I'm looking for is to learn best ways to design complex object interactions.
Also designing maintainable and expandable WEB applications that involve these complex objects, persistence with db , irrespective of particular language.
Pretty theoritic question? What to do? Am learning.