1

Just recently, our application expanded to support 4 different UIs.

We have business logic that is integrated into our data layer.

We do not have a physical business layer that separates our UI from our data layer. Often times in the UI, the database is being called directly. Obviously, this causes problems.

My question is, should I implement a physical business layer, and over time, migrate the existing logic in the data layer to the new business layer. Or should I keep the business layer in the same dll as the data layer?

What are your thoughts on adding a business layer to an application without one?

drizzie
  • 3,351
  • 2
  • 27
  • 32
  • Please clarify a bit. What do you mean by data layer. Do you have a data model and a separate data layer? How is the existing logic integrated in the data layer - do you have stored procedures? – Plamen G Apr 22 '15 at 07:03
  • Sorry, by data layer I was referring to data access layer. We use Linq to Sql and have all of our business logic in extension classes there. – drizzie Apr 22 '15 at 11:55

1 Answers1

2

You should definitely introduce some separation of concerns by doing things in different layers. Directly referencing the database from the UI is not sound architecture and will lead to tight coupling and difficulties in maintenance and extensibility later on.

The best time to do this separation is at the beginning, when there are no costs of refactoring involved, but if you expect the product to be expanding, doing it now will also bring significant benefits in terms of extensibility and maintenance.

Here is an approach for introducing a service layer that stays on top of the model and exposes the same functionality that gets reused by multiple UIs and gateways. This layer helps you unify your business logic across all your interfaces and all exposed services (if you ever need to expose functionality/data) which is very important - you definitely don't want to create and change things in multiple places when you can do it in a single place and guarantee 100% consistency.

P of EAA - Service layer

Regarding the part of the question about physically implementing the logic in a different dll, I think it is not that important and necessary - you will have the most important benefits of using separate layers without having to physically separate them. Maybe it will make sense if you plan on scaling up and you think that having multiple instances of the same layer on multiple machines will solve a problem of yours (e.g. using some king of load balancing approach for) but otherwise I don't think it is mandatory to do it this way.

Good luck!

Plamen G
  • 4,729
  • 4
  • 33
  • 44