Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Nov 09, 2012 06:55 AM by Kevin Gao
Nov 06, 2012 05:14 PM|LINK
My question revolved around proper object oriented design. Right now, we use a lot of web forms and no entity framework.
Let's say, as an example, I have 4 SQL database tables.
So in my C#, I make 3 classes, one called "products", "clients", and "orders" all in their own .cs files. Within these classes I just define the object as I did in SQL.
Usually, I'll make a seperate "controller/manager" class for each object, that handles CRUD operations for the objects.
My question is this.
Nov 06, 2012 07:04 PM|LINK
Would it be better to store the "orders" class/objects within a client class/object? Since I can never have an order without a clientID would it make more sense, and be more "proper" to say Client.Orders.Create() or just Orders.Create() as I do now?
Orders do not place or create themselves, so if you want to apply behaviour anywhere, mirror the real world. In the real world, a customer places an order:
What is the best way to handle a one-to-many relationship like my table "products_orders_REL"? Do I make a class/object specifically for that? What woulkd you call the class/object? Where would you nest it?
If you mirror the real world, your object model should have a client object that has a collection of order objects, each of which has a collection of order items.
Nov 09, 2012 06:55 AM|LINK
For your questions:
The method should be "Orders Client.Orders()". It is not necessary to have Create(). "Orders.Create()" will represent all orders, not specific to any particular client. The meaning is different.
Createing a class/object specifically for that is NOT a good idea. In your case, the design should be "OrderInfo Order.GetOrderInfo()". The OrderInfo class has the information of Product and Price.
Hope that helps.
MCSD, MCDBA, MBA