Home/ Questions/Q 6641811
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T23:51:18+00:00

Are there any disadvantages for using the same POCOs (in EF4 & WCF) across

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0