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?
Separate presentation layer from data entities
domain model;separation of concerns
Usually, decoupling roles and responsibilities is a good practice. That being said, decoupling is often preceded by an increase in the complexity of the code base which could, in some cases, outweigh the benefits. Nevertheless, let's  assume that this's not the case.You might be interested in the following patterns: MVC and MVP. Or in Onion Architectecture, depending on the size of the project. According to comments, looks like you already did choose MVVM. So far so good.So, the question spins around the next comment 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 as rule that in  presentation layer is better don't use EF classesLaw of Demeter may help you with the guidelines of your code conventions. We usually mention this law in the context of the interoperability among components at a low level, but it's also valid for higher levels of abstractions such as layers, tiers, etc.For example:Persistence Layer or DAL. Persistent entities classes live in and only in this layer. No business live here. The components at this level are in charge of retrieving and storing data into the different data storages. The model here can be as simple as a row mapping. The persistence data model is accessible only by upper layers through the proper abstractions. For example DAOs, Entity Managers, etc. Domain Layer or BL.  The domain data model and its services live here.  The business rules (logic) happens in this layer. Any need of persistence is delegated to the DAL. The domain model never exposes persistence entities to upper layers.  Upper layers do have access to the domain model through the proper abstractions. For example Repositories, Domain Services, Managers, etc. Usually, for simplicity, no DTO is needed yet. The domain is agnostic to the needs of external layers. The mappings to DTOs should be carried by those who need it. Finally, entities of the domain model no necessarily match entities of the DAL. There's not a 1-to-1 relationship between components at this level.Control Layer: Controllers lives here and they are the bridge between UI and the domain model.  They shape the facade to access to our domain (or data).  The access to the model is carried through the proper abstractions (repositories, services, etc). In order to prevent coupling between our domain and the consumer's domain, controllers do map domain entities to another model. DTOs, POJOS, etc. View models don't live here. The reason is simple, how the view model should look like is a UI concern.Postel's law may help you too for designing the abstractions between layers. My advice is, don't you try a heavy decoupling. There's going to be always a little coupling somewhere between the layers. So be flexible and follow KISS.The rules and conventions should server to a real propose. Don't state conventions for the state of the art. You have to identify first what kind of application you have. Otherwise, you might strive to stick with principles that applied to the project may result in an unnecessary increase in the complexity (as I introduced at the beginning of the answer). For example, implementing LocalDTOs for layers inter-communication. You probably don't need them, so don't strive to use DTOs everywhere. Following SOLID principles should enough to achieve loose coupled layers and components.