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.
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.