1

I am building a software where UI, Business Layer and Data Access Layer are tightly coupled in a single tier.

I want to decouple layers, because a change in the database can cause the change in my presentation layer.

Is it a good practice to always decouple the entity classes from the presentation layer by implementing a domain object (or "view" object)?

If I had a 2-Tier implementation I would use DTOs to transfer data between the UI and the Business Layer. With 1-Tier implementation, I would use a domain object (or whatever it's called).

I would define for each entity class one mapper class in my Business Layer that maps the entity with the domain object and vice versa.

Which approach would you take for that?

3

Is it a good practice to always decouple the entity classes from the presentation layer by implementing a domain object (or "view" object)?

Loose coupling and high cohesion are usually two fundamental principles that worth implementing. However, we have to bear in mind that implementing this kind of best practices have a cost. A remarkable increase of the complexity, which is often translated into more components to implement and maintain. A source code harder to envision and to understand at the first sight.

You'll have to weigth if the benefits of these practices offset the costs of implementation and maintenance. For example, if the source code is unlikely to change or if it changes very now and then, you might not appreciate the benefits any time soon. If your code is already testeable, probably either.

Which approach would you take for that?

I would give a chance to some well-known design patterns. As for instance MVC, MVP and MVVM. Onion Architectecture too, depending on the size of the application.

I was thinking about first rules and best practices and conventions at the beginning of a project. I think it makes sense, don't use the entities of Entity Framework in the view models.Instead of the EF classes, I can use a "view" object. I want to define a rule that in presentation layer is better don't use EF classes

Law of Demeter may help you with the guidelines of the code conventions. It's often introduced as a principle to design interoperability of components at low levels of abstraction. But it works for higher levels of abstraction.

For example:

  • Persistence Layer. Persistent entities live in and only in this layer. No domain business is implemented here. Components at this level are in charge of retrieving and storing data. The persistent model can be as simple as row mappers, Maps or arrays. The persistence data model is accessible only by upper layers through the proper abstractions (DAOs, Entity Managers, etc)

  • *Domain Layer *. The domain model and all the business rules live here. Persistence is delegated to the Persistence Layer. The domain model never exposes persistence entities to upper layers. Upper layers have access to the domain model through the proper abstractions (repositories and domain services). For simplicity, no DTO is needed. The domain is agnostic to the outer layers' needs. DTOs and mappers should be located in those layers that need'em. The domain model doesn't necessarily match 1-to-1 the Persistence model. They have different concerns, hence they are different things.

  • Control Layer. Controllers live here and they are the bridge between UI and the domain model. The access to the domain model is done through the proper abstractions (repositories and services, etc). In order to prevent coupling between UI and the domain model, controllers do map domain entities to another model. DTOs. DTOs are not View models. View Models belong to the UI.

Postel's law may help you too at taking decisions regarding interoperability among layers and tiers.

My advice is, don't you try heavy decouplings. There's going to be always a little coupling somewhere. Be flexible.

Following these and other principles (conventions, best practices, etc) should serve a real purpose. Apply them while they keep providing value to the application.

Remember that solutions should never be more complex than the problems they solve (ideally). KISS and YAGNI should help you out to remember this premise.

  • Thanks for your opinion, Laiv. I am building a WPF Application and I am using MVVM pattern. And yes, I am going to use a pattern like DAO or Repository and the DAL will use the ORM Entity Framework. I was thinking about first rules and best practices and conventions at the begining of a project. I think, it makes sense, don't using the entities of Entity Framework in the view models.Instead of the EF classes I can using a "view" object. I want to define as rule that in presentation layer is bettter don't use EF classes. – MrScf Jul 4 '17 at 5:00
  • I agreed. That's what I usually do. I will edit the answer as soon as I get in the office. – Laiv Jul 4 '17 at 5:46
  • I am curious to read which is your opinion about that. – MrScf Jul 4 '17 at 8:28
  • @MrScf check my edit. I came to the conclusion that a detailed answer (with examples and details of implementation) would not provide you with the right tools. Code conventions and principles vary from project to project, from team to team and from developer to developer. You have to find those that work for you and suits better your needs. I think you could find the set of best practices you need looking at some of the most renowned principles of the Software Engineering and its design patterns. You already are in that way :-) – Laiv Jul 4 '17 at 9:11
  • Ultimately, how your applications should be implemented depends entirely on your specific needs and requirements. – Laiv Jul 4 '17 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.