Understanding why we use data transfer objects for data contracts in place of database entites

Question

In situations where the client consuming a web service is looking for data that at present matches a database entity one to one (ie. GetAccount, GetTransactions); we still want to use a data transfer object (dto) to decouple the two to allow the database entity to change if needed, without the changes rippling through the entire system? If so, from a consuming standpoint, we don't want a client's model directly based on the data transfer object. We would want to cast whatever was being returned from the web service to a local model, for the same reasons we used a DTO in the first place? Do I have that right?

Answer 1

The DTO matches the shape of the data that you want to transfer. If that matches the underlying data model then so be it but that is by the by. You might at some point change the shape of the underlying data model but the DTOs would not change.

Also, a DTO is what would get passed by a web service to a client. If you have your data model defined on a server then you don't want a distributed client to have to know about that data model.

Finally, your entity classes might contain additional logic whereas a DTO is simply properties exposing data and nothing else.

Answer 2

Your application can have many conceptual layers. Data Layer, Business Layer, Service Layer, Presentation Layer to name a few. Each has a specific function with an input and output. The goal is how to design a system that is loosely coupled (i.e. things don't rely heavily on one another so any changes are isolated and have minimum impact). You want to maximise maintainability, improve re-use and maximise speed. The trick is to keep complexity down but build in some basic separation that allows you to move your design forward easily as you need it. Keep in mind YAGNI! YOU AINT GONNA NEED IT! People tend to look for and design the most complicated architectures for problems they will never encounter! The number of times I have heard "We have a separate data tier so we can swap out the database in the future"...yet I have never seen it happen! A simple Repository Pattern works.

As per previous poster, you have data in the database (in a physical model) that you want to get into your application transformed into a conceptual model. Any clients will then consume your conceptual model. I would do this immediately at or after your application code has retrieved the data from the database from your data layer. This ensures any changes made to your database are isolated from the rest of your application. Therefore you don't have to start changing your User Interface because you have changed the name of a database field. You just have to update your data layer.

If you choose Entity Framework as your data access strategy it will map your database to a conceptual model for you. If you are converting other data objects from one type to another look at technologies like AutoMapper. You can map your Entity Framework POCOs to a service contract (XSD). From the client perspective 'you could' write a client proxy that calls your web service, maps the returned service contract to a nice shared conceptual object model.

Keep it simple. Keep re-use and simplicity at the heart of what you choose. If you start seeing database column names in your client objects, you need to start thinking about putting in some abstractions in much earlier in your solution to insulate your app from changes.