What is the Difference Between Business Object and Business Logic
I am trying to structure my MVVM WPF application according to best practices. I have to start with a lot of existing code, so there is no way for you to address all the structural flaws at once. I like the following solution structure.
This separates the solution from the next projects; BusinessLogic, BusinessObjects, Infrastructure (common reusable utilities), WPF Shells and Modules (application components to be injected using an IOC container).
I understand that a business object is a human world object whereas business logic is implementation details as discussed in this question.
What are business objects and what is business logic?
So, using MVVM, the business object just becomes a dumb container that actually does nothing but wait for its properties to be changed by external business logic? I don't see how you decouple the business object from the business logic to the point where you can have them in separate assemblies.
Take the following extremely 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 framework described above (at least in my opinion), the SizeChart class will be the business logic and the Chart class will be the business object, but placing them in different projects will be a circular dependency. Is the business logic of the SizeChart class or a business object and where in the solution framework the SizeChart class should exist if I accept this proposed MVVM solution framework?
Sorry if this is an incredibly obvious and straightforward question for some people, but it's difficult when you can't start from scratch to find out how best to start converting poorly structured code to well-structured code.
source to share
http://en.wikipedia.org/wiki/Business_object
Business object . A type of understandable object that is an actor within a business layer in an n-tier object-oriented computer program architecture. While a program can implement classes that usually end in objects that manipulate or execute behavior, a business object usually does nothing by itself, but contains a set of instance variables or properties, also called attributes and associations with other business objects, weaving a map objects representing business relationships.
http://en.wikipedia.org/wiki/Business_logic_layer
Business logic layer . The Business Logic Layer (BLL), also known as the Domain Layer, is a software development practice. Within objects, BLLs can be further divided into business processes (business activities) and business objects. Business process objects usually implement the controller pattern, i.e. They do not contain data elements, but have methods that organize interaction between business objects.
So basically a business object models an object (usually a real world object like Employee or Account), whereas business logic facilitates communication between business objects and between other layers of applications.
I think the most appropriate answer was given by Daniel Hilgart . His answer was that he does not separate business logic from his objects, because that leads to .
While I think the following MVVM WPF solution structure as suggested by Paul S Patterson is good, I don't think it fits everyone.
Creating different business logic and business objects probably works best if your business objects are Data Transfer Objects (DTO) for example. Linq to SQL, rather than a more complex object like composite, which can have a closer relationship with business logic.
source to share
Business object is a rather amorphous term - is it a DTO, POCO, or a mixture of one with some kind of business logic thrown in?
For me, I would think of something else - Chart
and SizeChart
- these are both controls, not "business objects" or "business logic". It is not a fact that they have the names of the UI sensing functions, but they actually do the UI or do the related work (size and drawing). The collection of data they operate on will be separate and assigned to controls before calling Size
or Draw
.
Note that this answer is MVVM agnostic as it is a bit of a red herring - your question is more closely related to the general n-tier design in which you also include MVVM.
source to share
I recently came across something similar to the project.
We have a web application that allows the admin to create groups. One of the necessary rules was that you could not create two groups with the same name. What we ended up with was create a very simple object, a group, and then create a service called GroupService. GroupService checks the rules so that the user calls GroupService.Save (Group), the service shuts down and checks the previous named groups. If the name is found, an error is returned to the user and no save occurs.
In our case, the hierarchy is that Controller has Services, Services have repositories, and repositories finally commit the database. At the heart of each of these abstractions is the Group model. But our model is not just a "dumb" object. It contains validation logic in the data fields themselves and has aggregate properties to simplify data binding.
Expanding this to conewcept MVVM, I would have thought the View Model would have a service that contains the business logic and the model that needed to be included in the view. Obviously the View will bind to the ViewModel, but the ViewModel will have an instance of the Model object to bind.
source to share