Simple OOP Design question

Simple OOP Design question

Old forum URL: forums.lhotka.net/forums/t/8186.aspx


EShields posted on Friday, December 18, 2009


I am in the process of building a ntier app that uses dumb business objects that are handled by "Managers" and populated by a custom DAL.  My question is this...  What is the best way to handle data that is many to many in the Database?  I have my link tables but I am at a loss as which is the proper way to build classes and persists this data.

For example if I was building a shopping cart and had the following Tables:
Products, Orders, Order_Products

Obviously the last table links Products to Orders so I would build a Product Class and an Order Class but what is the best way to have the Orders class contain a collection of Products for Orders?  Do I need to create a very simple class that contains only the ProductID, OrderID is a collection/list property of the Orders Class called something like OrderProducts that is just another dumb class to hold data then build the cooresponding DAL class for it that only talks to the link table "Order_Products"?

Thanks

RockfordLhotka replied on Friday, December 18, 2009

CSLA .NET is designed to support smart business objects that are designed around your business use case (or story, or user scenario - which ever term works for you).

This usually means your objects look more like your UI requirements than like a relational data model. You may be able to force CSLA to work as an ORM, but that's not really what it is intended for.

If you really want dumb objects (DTO or entity objects), and to have them handled by "manager" or service objects, you might be better off using some other framework that is designed around that philosophy.

I talk about M:M relationships in Expert 2008 Business Objects, and provide an example implementation in the ProjectTracker sample app. Modeling M:M in objects means the object model itself is almost never M:M though, because that's a relational concept, not an OO concept...

If I'm in the add an order use case, I'll have OrderEdit and LineItemEdit objects (with a LineItems collection to connect them). Each LineItemEdit object sort of represents a 'product', but really it represents the fact that the user wants to purchase a product.

A ProductEdit object would be used in the edit a product use case, but it is hard to imagine where the user would edit order data as part of the process of editing product data. So it is highly unlikely that ProductEdit would have a collection of orders - unless you have a truly unique business requirement of some sort.

I could see where you might have a read-only collection like OrderList of OrderInfo objects so the user could (perhaps optionally) get a look at the orders for a product while they edit the product - that sort of informational display is relatively common - but in such a case you'd have a ReadOnlyListBase and ReadOnlyBase set of classes to handle that sub-section of the use case.

Copyright (c) Marimer LLC