Why do we need a business logic layer? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers.

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

I'm developing ASP.net application which use web services. There are no data base connections directly from my application -- all the activities are ha开发者_JS百科ndled using web services.

In the UI layer I can do the data customizations and validations using a few lines of Linq code. What are the drawbacks if I don't have a business layer for my application?

Putting all your validation and business logic into its own tier is good for many reasons.

It keeps all of your business logic localized, and in one place. Future changes will be much easier as a result.
It allows you to more easily unit test your business logic. This is a big one. It's very difficult to write automated unit tests against your business logic if this code is tightly coupled to your web page, or windows form.
It keeps your UI much slimmer.

See also: single responsibility principle (in a nutshell, your UI classes should do UI things, not business-logic things).

If your UI code handles non-UI-related things, such as business logic, then the code lacks separation of concerns. Say you want to use a completely different UI - for example, you want to switch from a web service to creating an actual web site/application. You've have to completely reproduce all of your business logic in the new UI layer because the business logic is tied to the current UI.

Separation of concerns (SoC) is the process of separating a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity of programming and encapsulation (or "transparency" of operation), with the help of information hiding. Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer).

SoC and SRP makes it easier and simpler to:

maintain existing code
reuse existing code
write tests, especially unit tests
write robust code, e.g. code in which changing one component is less likely to break other components

Here's an analogy (yes, it's simplified): a car is controlled in part using a steering wheel and a gas pedal. The steering wheel controls the car's direction, and the gas pedal controls the car's speed.

It would be harder for the driver to operate a car safely and precisely if one device controlled the car's direction and speed. For example, if the driver had to push the steering wheel in or pull it out to make the car go faster or slower, they might risk changing the car's direction at the same time. Likewise, the driver might accidentally change the car's speed when trying to turn.

Keeping the two concerns (speed and direction) separate makes it easier and safer to drive.

Your UI shouldn't know about your business logic, it should only know about displaying stuff and responding to user interactions.
Your data access code shouldn't know about business logic, it should only know about getting and saving stuff to the database.
Your business logic shouldn't have persistence or UI concerns.

Additionally, as the SOLID principle SRP states - a class should only change for one reason. If you don't separate your business logic, you violate this principle.

Ask yourself the question: Is there business logic in this application?

Or rather: Are you

Simply providing basic out-of-the-box web CRUD functionality to a relational database or are you
Creating an app in which there are some important underlying concepts that you have (or should have) modeled into classes. This could be concepts relating to rules and entities in the business domain that your application deals with or algorithmic concepts important to the proper handling of your application's requirements.

In the first case I would say that a business layer may actually add unnecessary complexity to a simple app.

In the second case you should certainly create some business objects and try to disentangle them from the database and your UI (high cohesion, low coupling, encapsulation with information hiding). Make your business logic available for independent unit testing, and ask yourself whether it could quickly be migrated from an Oracle to SQL Server database or from having a winforms UI to being a silverlight app using the same business logic.

What happens if, in the future, you want to use the same validation/business logic outside this particular UI? maybe this application would need to expose a webservice that incorporates the same logic? or you might be working on a client/server application, a standalone windows application, and an asp.net web application all of which use the same business and validation logic - in that case, separation of concerns will save you a lot of redundant code and a lot of opportunities for errors (thereby reducing debug time).