Any disadvantages when using POCO + Entity Framework at the levels and not using data transfer objects?

Question

Are there any disadvantages to using the same POCOs (in EF4 and WCF) for levels (DAL, BLL and Presentation) and without DTO? Clients and services are all .NET, and the entire application is not great.

I ask this because moving the same data between layers in different formats and making conversions and comparisons seems difficult and adds complexity. It takes more time to develop and maintain and is error prone. I'm not sure if DTO is worth adding, even if DTOs are generated at run time or DTO generators are used.

I would like to see some opinions as I begin to develop and code a new web application.

Answer 1

One of the main motives for using DTO is the need to transfer representations of objects for wiring.

If you use domain model objects within the same process, you can just use the same objects.

If, on the other hand, you plan to serialize your objects and send them to other processes, for example. through a web service, then it is usually best to do this with a DTO that is consistent with data contracts between the two processes. Data annotations can be used to enrich this contractual agreement. Both processes can potentially use the same assembly of data contracts for serialization and deserialization back.

Each process in such an architecture is likely to have a different purpose (hence, separation) and, therefore, will have different requirements for objects, for example. one can be a graphical interface associated only with a presentation, it can be a business logic word associated with mutating objects that allow them to interact adhering to business rules, and the other can be a level of access to data related only to conservation, and the other can be denormalizer associated with the conversion of objects for the reporting mechanism, etc. This means that the only probable commonality of requirements between the levels is the presentation of the data, that is, the DTO or the data contract, and not the behavior of the model object with a rich domain. In the above examples, the only layer that needs a rich object with behavior is the level of business logic.

DTO may also be the best way to transfer object representations between AppDomains, if that is what you need to do.

Answer 2

By wire means that your data is visible through the wire.

After successful user authentication, any network tool can display all the transmitted data. If you pass the whole entity, and you only show the past of the entity in ui, then you are under the assumption that the user will not see your hidden data. But with any network trace tool, everything is visible.

You have to imagine that you are really sending the full data, and the user interface is just a presentation.

So, if a user can view data through a network trace, then there is nothing to worry about.

But remember, someone with a bad intention may try to manipulate data that you might have ignored, given that the user will never have access to it. For example, you can create a username read field and your ui will not allow the user to change, but someone can easily write the wcf client code to connect to your service.

Most problems are due to foreign keys; if someone manipulates foreign keys, it will be difficult to verify ownership of the object.

You must assume that every request on the wire is and will be harmful, and security should be checked for all possibilities.

Answer 3

The flaw begins, and this is just an example, but imagine that your user interface designer is faced with a simple and innocent question. Can we not save the position of x and y, where the object is drawn on the screen in the entity itself? Can I have the Select property for an object that indicates whether it is currently selected or not? And you think: Selected property, damn it! I can not write this to the database, it makes no sense. And then they want your POCO to implement INotifyPropertyChanged and receive some custom events, etc.

The advantage of DTO and mapping is to separate your layers. You are improving your ability to customize your objects to the requirements of each level.

There are currently some neat mapping tools that should make this task pretty simple. AutoMapper is one of them. Code generation with T4 templates is different.