I’m having trouble modeling the Business Objects of my application.
In my domain I have substantially a list of bills of orders, and for every bill I have the pallet that contains the materials to satisfy the orders. A bill is a complex object, it contains several properties, and a list of orders, which in turn are complex objects. The pallet object is likewise complex, it contains several properties, a list of stacks and a list of distributions of the contained stacks; this lists too contain complex objects.
The software is structured as 3-layers application (data access layer, business logic layer and presentation layer); Presentation layer follows MVVM pattern, and in DAL layer I’m using a Repository class for every data model entity.
My problem is how to define Business Objects. For example, in one view I have to show the list of all the bills with the details, specifying the status of the associated pallet, so my classes may be:
Instead, on another view I have to show the data of the pallet under processing, and some data of the associated bill, so in the classes the direction of the relation between Bill and Pallet should be opposite:
So, how should I design my classes? These are some my observations:
- I could model my domain with different classes depending on the use case, but I don’t think is correct. In my opinion for a domain only a single set of business classes should exist, so I have to build classes that I can use for all the use cases
- I could establish a bidirectional relation between Bill and Pallet, but I think is better to avoid it. Moreover, this solution would force me to implement some kind of Lazy Load, increasing the complexity
- I could remove the relation between Bill and Pallet, so let the classes less coupled to use cases, and create classes on the view models (so in Presentation layers) for the specific use cases. The problem in this case is that I should move some business rules on Presentation layer.
- I could remove the relation between Bill and Pallet, so let the classes less coupled to use cases, and create classes on BLL for the specific use cases. The problem in this case is that in my BLL I would have very specific classes, so it would become a less generic layer.