business layer 3

Why the second layer in 3 layer mod开发者_开发问答el known as "Business" layer?

---

Because the business logic resides there. That is - the logic that is specific to the business scenarios.

Other layers should not have such logic. Front end should display and gather data, database should store data, dao should retrieve and save data.

The business layer should perform the logic based on what is coming as input from the UI, and from the DB.

It's 'business', because every software backs some business.

---

Because its specific to the nature of the application - a charity, online retailler and estate agents might all use the same webserver and database - but the bit in the middle is very different.

---

OK, here my 2 cents.

Why? Because that is how it is defined in the N-Tier paradigm. We cannot ask why something is named as such when it is defined as such.

N-Tier paradigm is an old one - more than 10 years old. N-Tiere design while at some point helped separating view logic from business logic, now is not trendy anymore.

Today, Domain Driven Design aka DDD is the new paradigm where looks at the domain logic and builds the system on that. Domain logic is everywhere, in database, in the UI as well as in the middle layer. So really your tables will be called Order, Topping, etc if you are making software for pizza shops whil it will have Account, Transaction if you are developing software for a bank. So business logic is everywhere, in the middle tier as well as in the UI or database.

So now while layered architecture is still accepted as a good architectural approach (which has a middle layer which is not called "business layer" anymore), N-Tier is not.

---

In an OO application I like to think of the business layer as business rules, processes or workflows that are applied to the objects. However in many cases I have seen this to mean that the objects become nothing but POCO's (Plain Old C# Objects in C#, POJO's in Java etc). The problem with this is that the object's behaviour becomes detached from the object and moved into arbitrary "Business Logic" classes.

My personal belief is that the "Business Layer" should act upon objects but not replace object an object's behaviour. This also allows for better implementation of other practices such as Open Closed Principle using inheritance and polymorphism.

Consider this example "OCP" where the Area class would be the "Business Layer" but the various Shape objects contain the behaviour logic for each type of shape. This way the Area code rarely, if at all needs to change.