I’m trying to structure my WPF MVVM application according to best practises. I have to start with a lot of existing code so don’t have the option of resolving all structural flaws straight away. I like the following solution structure.
This separates the solution into the following projects; BusinessLogic, BusinessObjects, Infrastructure (Common reusable utilities), WPF Shell and Modules (application components to be injected using an IOC container).
I understand that the business object represents the human world entity whereas the business logic is the implementation details as discussed in this question.
What are Business Objects and what is Business Logic?
Therefore using MVVM does the business object just become a dumb container that doesn’t actually do anything other than wait to have its properties changed by external business logic? I don’t see how you decouple the business object from the business logic to the point of being able to have them in separate assemblies.
Take the following hugely simplified code:
public class Chart
{
private SizeChart _activeChartSize = new SizeChart();
public void Draw() {
// Size the chart object
_activeChartSize.Size(this);
// Do other draw related things
}
}
public class SizeChart
{
public void Size(Chart chartToSize) {
// Manipulate the chart object size
}
}
In the context of the MVVM solution structure described above (to my mind at least) the SizeChart class would be business logic and the Chart class would be a business object but placing them in different projects would be a circular dependency. Is the SizeChart class business logic or a business object and where in the solution structure should the SizeChart class reside if I adopt this proposed MVVM solution structure?
Apologies if this is an incredibly obvious and simple question to some people but it’s difficult when you can’t start with a clean slate to know how to best start transitioning poorly structured code to well structured code.
http://en.wikipedia.org/wiki/Business_object
Business Object: A type of an intelligible entity being an actor inside the business layer in an n-layered architecture of object-oriented computer programs.
Whereas a program may implement classes, which typically end in objects managing or executing behaviors, a business object usually does nothing itself but holds a set of instance variables or properties, also known as attributes, and associations with other business objects, weaving a map of objects representing the business relationships.
http://en.wikipedia.org/wiki/Business_logic_layer
Business Logic Layer : A business logic layer (BLL), also known as the domain layer, is a software engineering practice of compartmentalizing.
Within a BLL objects can further be partitioned into business processes (business activities) and business entities. Business process objects typically implement the controller pattern, i.e. they contain no data elements but have methods that orchestrate interaction among business entities.
So basically a business object models an entity (usually a real world object such as Employee or Account) whereas business logic facilitates the interaction between business objects and between other application layers.
I think the most appropriate answer was given by Daniel Hilgarth. His answer was don’t separate the business logic from its objects, because this leads to an anemic domain model.
While I think the following WPF MVVM solution structure proposed by Paul S Patterson is a good one I don’t think it’s appropriate for everyone.
http://www.paulspatterson.com/technology/dot-net-development/mvvm-and-wpf-for-vb-net-series-2-part-1-again/
The creation of distinct Business Logic and Business Object projects probably works best if your business objects are Data Transfer Objects (DTOs) e.g. Linq to SQL rather than a more complex object such as a composite that may have tighter coupling to the business logic.