Hi,
I've Always tried to make dto's correspond to a table in the database I'm using. But is it fair to say that a dto should rather correspond to the Query I'm using instead? Let's say you have a Reservation table, and then a ReservationDto which includes the fields Id, FacilityTypeId, StartDate, EndDate. where FacilityTypeId in the table is a foreign key to the FaciliType table from where I get the FacilityTypeName.
If I should be strict in using dto's to mirror the tables, then I also have to have a FacilityTypeDto in this scenario, but if I instead let my ReservationDto correspond to my Query, which uses a JOIN with my FacilityType table to get the FacilityTypeName I only have to Query the database for information once, hence making the whole thing simpler imo.
It would just be interesting to hear anyones thoughts in this.
Thanks,
Peter
I've always had the DTOs mirror the tables exactly, but I'm assuming something like linq2sql or EF. Then your context has methods for proc calls, and you write your queries using Linq. Of course the biggest benefit is generating your DTOs from the database; don't write them by hand and you'll get things automatically like navigation properties.
We've tended to have the DTOs contain the data in a structure easiest for the business object to hydrate from and populate to - child objects typically are a DTO-classed property on the root object's DTO. We do hand-roll our DTOs but I've never considered it too onerous.
That said, my guess is that the route Andy mentions above makes the data access layer much easier/efficient to write.
I think one thing that is clear is that you really want these to have no inherent logic to them - you want them to really just be containers of data... virtually all of not all of the properties in our DTOs are automatic properties ... {get; set;}.
In this particular scenario I don't use EF, but have my Sql-query in my Concrete Dal (DalSql). What I mean is that with a Query like the following I don't need to go to the database again to get the actual value of FacilityType.Name. Then I will have a dto that corresponds to the Query instead.
SELECT HousingFacility.HousingFacilityId, FacilityType.Name, HousingFacility.Name, Rooms, Beds
FROM
HousingFacility
Left
Outer Join Reservation ON HousingFacility.HousingFacilityId = Reservation.HousingFacilityId
and Reservation.StartDate <= @ResEndDate
and Reservation.EndDate >= @ResStartDate
Left
Outer Join FacilityType On HousingFacility.TypeId = FacilityType.TypeId
WHERE
Reservation.HousingFacilityId Is Null
I absolutely agree, no inherent logic what so ever should be in the dto's, and I also only use automatic properties. Like you say, the dto's are just containers of data but should these containers correspond to the Query or the table? If I have joined tables, and if I follow the strict approach with dto's corresponding to the table fields, then I have to have several calls to the database, with several dto's for each table instead of having just one dto that corresponds to the Query (see my answer to Andy too).
Hi,
When I need DTOs I always make these fit the query/data structure.
When I am using LINQ then anonymous objects is a nice alternative and when using direct SQL you will always get the best performance by using the DataReader directly and materialize into BusinessObjects.
Copyright (c) Marimer LLC