Any disadvantages if using POCO + Entity Framework across the tiers and not using Data Transfer Objects?_问答_开发者

Are there any disadvantages for using the same POCOs (in EF4 & WCF) across the tiers (DAL, BLL & Presentation) and doing without DTOs? The clients and services are al开发者_如何学Cl .NET & the whole app is not extra big.

I ask this because moving the same data between the tiers in different formats and doing conversions and mappings seems like a hassle & adds complexity. It's more time consuming to develop and maintain & is prone to errors. I am not sure if adding DTOs is worth it, even if the DTOs are generated during runtime or DTO generators are used.

I would like to see some opinions as I am starting to design & code a new web app.

One of the main motivations for using DTO's is the need to transfer object representations across the wire.

If you are using your domain model objects within a single process then you may well be ok just using the same objects throughout.

If, on the other hand, you are planning to serialize your objects and send them to other processes, e.g. via a web service, then it's usually better to do this using DTO's which form agreed data contracts between the two processes. Data annotations can be used to enrich this contractual agreement. Both processes can potentially use the same data contract assembly to serialize from and deserialize back to.

Each process in such an architecture is likely to have a different purpose (hence the seperation) and will, therefore, have different requirements from the objects, e.g. one may be a GUI concerned with presentation only, one may be a business logic layer concerned with mutating the objects, allowing them to interact whilst adhering to business rules, another may be a data access layer concerned with only persistence and another may be a denormalizer concerned with transforming the objects for a reporting engine, etc. This means that the only likely commonality in requirements between the layers is the data representation, i.e. DTO or data contract, rather than the behaviours of a rich domain model object. In the examples given, the only layer which needs a rich object with behaviours is the business logic layer.

DTO's may also be a better way to transfer the object representations between AppDomains, if that is something you are required to do.

Across the wire means your data is visible across the wire.

Once user has successfully authenticated, any network tool can reveal all the data that is passed. If you are passing entire entity and you are showing only pasts of entity in the ui then you are under assumption that user will not see your hidden data. But with any network trace tool, everything is visible.

You have to imagin that you are actually sending complete data and UI is just a presentation.

So if it is ok for user to see the data through network trace, then there is nothing to worry.

But remember some one with bad intention may try to manipulate data, that you may have ignored considering user will never have access to it. For example, you may make a username readonly field, and your ui will not allow user to modify but someone can easily write wcf client code to connect to your service.

Most problems happen because of foreign keys, if anyone manipulates foreign keys, it will be difficult to verify ownership of object.

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

The disadvantage starts and this is just an example, but imagine your UI designer comes along with a simple and innocent question. Can't we store the x and y position of where the entity is drawn on the screen in the entity itself? Can't I have a "Selected" property on the entity that specifies if it is currently selected or not? And you think: A Selected property, hell no! I can't possibly write that to the database, that doesn't make any sense. And then they want your POCO to implement INotifyPropertyChanged and get some custom events and so on.

The advantage of DTOs and mapping is to decouple your layers. You're improving your ability to customize your objects for the requirements of each layer.

There are some neat mapping tools nowadays that should make this task pretty easy. AutoMapper is one of them. Codegeneration with T4 templates is another.