When reading, I keep seeing references to what they call Business Objects. I've looked up on Wikipedia and such but I keep not getting what a Business Object is.
Is there any easy explanation of what it is for someone that doesn't know a thing about software architecture and such?
Also, what is Business Logic?
This is easy
Every entity in the system, representing the human-world object which the system is expected to interact with is a business object.
The human-world logic in the system around manipulating business objects is a business logic.
This is opposed to the objects and logic being part of the implementation details.
For example in the multi-tier trading system order/trade will be business objects, but heartbeat will be implementation detail.
The logic of encoding order/trade objects for streaming will be implementation detail, while the logic of changing the order state to 'completed' once trade arrives is a business logic.
Well, a Business Object is generally considered to be a class that represents an Entity, e.g. a Book or a Store. Such a class has certain properties like price, colour, width, isbn number etc. In Java or .NET, it consists of so-called setters and getters, i.e. methods that set or get those properies.
The Business Logic on the other hand is that part of a program that works with that properties, i.e. how is this book sold. The business logic layer uses the business objects in order to access the database.
hey devoured, I had trouble with this terminology when I started developing too.
Basically, the only reason the word "business" is used, is because the terminology developed within the context of commercial software. So in this sense, it is assumed that the software is been built for business purposes... as opposed to say, artistic, aesthetic, or creative purposes.
So, business objects are simple code representation of real world "business" objects. So, you might have a Product Class, or a Employee Class.
Business logic, is logic within the application that is specific to the "business" the software was designed for. So, things like tax calculations, or how products related to customers... that kind of thing.
Note that the idea of Business objects or Business logic would not apply to video game development, or artistic development.
It also wouldn't apply to some frameworks, or libraires, like ORMS or unit testing libraries, as an example, because they are reusable components which are not specific to any "business".
In traditional 3 tier programming you have three logical layers or tiers. You have a presentation layer which is the User Interface, the bottom layer would be the database layer. The middle layer would be the business objects layer. As pointed out above the business objects should be abstracted in that the site might not be about business at all. It is a layer of abstraction that makes it easier to make changes to the presentation layer or to switch to a different data source.
If your user interface level has no or very little code behind it. It makes it easier for designers to work with programmers. The designers can change the look and feel of the site without the programmers having to do a substantial rewrite of the code that makes that site work. With the business objects layer you do the heavy listing of the site. You make calls into the database layer without the business object knowing whether your database layer is in XML or relational database. And the business object layer then would update a response to the UI layer. Typically the example used is for a bank transaction. In the user interface a client enters the amount he would like to transfer from his savings account to his checking account.
The business object layer will contain the business rules for the bank . That means it will check the balance of the users savings account and make sure the amount to transfer does not exceed the balance of the account. The business layer will contain the classes that actually calculate the new balances for both the savings account and the checking account and it will alert the database layer to update the database.
Business Object:
class User {
long id;
String fullNames;
int age;
}
class Book {
long id;
String bookTitle;
}
class Sales {
long id;
long userID;
long bookID;
}
Business Logic:
class BookSalesController {
private User user = new User();
private Book book = new Book();
private Sales sale = null;
public Sale sale(long saleID) {
String query = "SELECT * FROM Sales s WHERE s.id = :saleID";
....
.... execute the query
// Assuming we have our Result Set here by now
if (rs.next()) {
sale = new Sales(rs.getString("User Names"));
sale.setUserID(rs.getLong(userID));
sale.setBookID(rs.getLong(bookID));
}
return sale;
}
}
A definition of a business object is difficult to get on the search engine as it will tell you that Business Objects is a company acquired by SAP. But that is not what most people look for.
A business object is the the encapsulation of business logic model a business scenario.
For eg: In procurement domain : there is a whole list of activities that need to be performed. From Spend Analysis to Requesting of Information for the products to Generating the contract for the negotiated term. So in this particular scenario , a document like RFI (Request for information ) can be considered to be a instance of a RFI Business Object (It will have all the logic related to process like validation etc).
SAP series business object is different with the business object inside the oracle'core design pattern which interact with application service layer ... yes, business object does work with composite entity , but it has business logic , it can carry business state , some easy adjust methods and they are business info carrier with exchangeable the dynamic states and cross among application tiers or domains , but when at different context , it has different detailed specified name , for example, we can say web service request is a business object in xml format ...it is not the same as data entity
