Why Shouldn't we embed business logic in UI layer?

Hmm the only point I can think of is that it gives less re usability.Harder to distinguish code from the UI logic. From the MVC architecture, we sho开发者_Go百科uldn't we use domain logic in UI Layer?

---

In addition to what others have said, it results in code that is virtually impossible to unit test. Additionally, the design of of the code is tightly coupled and has low cohesion. These two attributes can lead to maintenance nightmares on large code bases.

---

because your UI can change over time. but the business logic stays the same. Or, you may want to change the logic, but keep the look and feel.

Mixing them together just make it hard to apply the changes and error prone.

---

Separating concerns has several important benefits:

1. It's easier to understand different functions if they are physically separate
2. It's easier to replace modules that are loosely-connected to a system
3. It's easier to modify code if you need to think at only one level of abstraction at a time.

Number 2 is particularly relevant here: separating business logic from UI means that you can have multiple UIs -- web, desktop, mobile -- for the same back-end.

---

Putting business logic in the UI layer makes both the business and UI logic harder to understand and limits the ability to independently change/reuse business and UI logic. In practice wanting to change/reuse these concerns independently is common, since conceptually they're not even tangentially coupled.

---

Suppose that you have created a big Web application and put it in the View all business logic (BL) one day your customer says that need to change the application and move to the Desctop application, it will be hard to migrate all code. if you separate the BL code from view it has the following benefits: 1. is easy to test code 2. maintain 3. change 4. and scale and you don't violate the Separation of concerns principle