Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Aug 19, 2012 09:43 AM by HeartattacK
Aug 18, 2012 08:57 AM|LINK
I have been confusing my self over this one for a week now :-)
Say I have a complex DTO class, containing some fields and properties and some other DTO classes. For Example
Public HotelID as INT
Public location as Location (DTO Class)
Public Contact as contact (DTO Class)
The above is made from a SQL statement where the Hotel info is the main table and the location and contact classes are populated from tables that are joined onto the Hotel Table.
All of the above am fine with and get on well doing it this way.
The problem comes when I try to update them. If I am passing back the whole hotel class to an update method, then the class needs to be able to update the lot by either a update (with joins), a method that passes the sub class to the another method to cal
update just that table - or in my UI I need to call a method for each table.
The problem is if I have a method that updates the whole object with joins, then what happens when I need to update just the location table, I need a method for that anyway
The above probally does not make total sense, but the way I see it you can either make you DTO classes close to real life things like Hotels, or close to DB tables like Hotel. When selecting and populating the object this is all very well, but how is this
handled in the UPDATES when you maye need to update one table independantly of another.
Is the best way to update a Db table using a DTO
Currently in my BLL(not the hotel class above), I have done this, but it is not really Business Logic, it is Db Logic
Resort has a sub DTO class of Map and a one for the council stuff
If Not Resort.Map Is Nothing Then
Dim Map As New MapsBLL
If Not Resort.Municipality Is Nothing Then
Dim Gov As New GovenmentBLL
I think I just need to know if I am on the right track and what is the best practises
Aug 18, 2012 10:29 AM|LINK
On of the purposes of DTO objects is to liberate what the client has to know from underlying inrastructure. If your DTO follows the exact same schema, then what's the point of having it? For the updates, I would much rather recommend having separate DTOs
for the two different use cases. The DTO for the updates should only contain the bare minimum of information that the client needs to send to the server to carry out the associated operations (and be as flat as possible). The server is then free to interpret
that DTO and make whatever underlying updates that may be necessary. This also means you can change stuff on the server and the client independently.
Aug 19, 2012 08:57 AM|LINK
Hi Thanks for the reply.
I am not putting all of the schema in DTOs, just certain tables.
I read on here somewhere, cant find the post that a DTO should be indentical to the table. Say for example I have a 26 column table containing info about a holiday resort, then the DTO should more or less have 26 fields. In my case that is mostly OK
When I have a class that is made up of sub classes as I described above, then this is popultated by JOINing tables in the DB.
You mention seperate DTOs for updated, do you recommend one per table or the DTO still object based, the same as then once used to populate the class.
Say I have a class called Resort used for DB SELECTS and one called ResortAdmin used for Updates.
The populated object being sent to the update method is based on the class 'resort', but the update method is expecting to see the object based on the class ResortAdmin, so there is a mis match.
Is it then best to have a seperate set of classes or methods for DB Selects and one for updates
In my web app I have made this work all ways, it is just the more I try and follow a better pattern.
Thanks for your help
Aug 19, 2012 09:43 AM|LINK
If you read a DTO should be identical to the table then that's probably one of the worst pieces of advice you'll ever get. The whole idea of a DTO is to provide a buffer, a "shield" if you will - an agreed contract between implementation and client. This
enables you to change implementation without breaking all clients. DTOs should have the info they need to maintain a lasting (possibly versioned) contract. Tying them to the table schema makes this very difficult and in cases impossible.
complicated business rules where one schema and one approach will not work. This is where concepts like CQRS come in. If your application is so simple that DTOs can afford to be the same as table schemas, then don't even have the DTOs - simply use the data
objects (perhaps POCOs) in a simple two tier manner. If abstraction is needded, think in terms of behaviour and design for such. If not, simply do two tier - abstractions will simply slow you down.