What is the difference between a business object and business logic

Question

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.

http://www.paulspatterson.com/technology/dot-net-development/mvvm-and-wpf-for-vb-net-series-2-part-1-again/

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.

Answer 1

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.

Answer 2

Business object is a rather amorphous term - is it a DTO, a POCO, or a mix of that with some business logic thrown in?

To me, I would consider something different - Chart and SizeChart are both controls rather than "business objects" or "business logic". It's not the fact that they have UI sounding function names in them, but that they are actually doing UI or rendering related work (sizing and drawing). The collection of data that these work with would be separate and would be assigned to the controls before invoking Size or Draw.

Note that this answer is agnostic of MVVM as it is a bit of a red herring - your question is more closely related to general n-tier design in which you also incorporate MVVM.

Answer 3

I ran into something similar on a project recently.

We have a web app that allows an administrator to create groups. One of the rules that was required was that you couldn't create two groups of the same name. What we ended up doing was creating a very basic object, a Group, and then creating a service called GroupService. GroupService does the rule checking so that when a user calls GroupService.Save(Group), the service goes out and checks for prior groups with the name. If the name is found, an error is given back to the user and the save doesn't occur.

In our case, the hierarchy is Controller has Services, Services have Repositories, and Repositories finally commit to the database. Running throughout each of these abstractions is the model, Group. But our model isn't just a 'dumb' object. It does contain the validation logic on the data fields themselves and has aggregate properties to simplify databinding.

Expanding this to the MVVM conecept, I would think the View Model would have the service that contains the business logic and a model that was to be incorporated into the View. Obviously the View would be bound to the ViewModel, but the ViewModel would have some instance of the Model object to bind to.