I'm extending an existing application, which has an attempt at a logical tier design, using DTOs, a Services layer (business logic), and a DAL. However, as I'm investigating more about DTOs, my existing system doesn't quite fit what I'm reading about DTOs. For example, my DTOs contain all the properties in the underlying database table. Naturally, on many UI screens, I don't want to show all the properties of the DTO, so I'm doing a lot of
dataGridView.Columns(0).Visible = False all over the place.
What I've read about DTOs is that they should only contain the fields that are to be shown/used in a given context (e.g. a particular UI screen). I've also read that you should have different DTOs for creating, updating, and showing the underlying business entity (i.e. these different DTOs for Product) if the fields being shown/used are different for each context.
It's kind of hard to make sense of it all, as many posts/articles do not have a comprehensive explanation or code example. They are all fragments that are hard to put together. Some only give the simple "this is a DTO for Student: Name, ID". Almost no real business entities in a system are that simple.
So my question, while rather general, is: How do you design a solid, maintainable DTO architecture for (for example) a simple business object, such as Product. Let's go by some assumptions:
- The Product database table has fields: ProductID, ProductName, IsActive, CreateDate, CreatedBy, UpdateDate, UpdatedBy
- Product is created in a screen accessible by system administrators (i.e. the "master list" of products in the system, where the admin enters data for fields ProductID, ProductName, IsActive. (ProductID is sourced from another master data system, so is user-entered.) CreateDate and CreatedBy will be handled by the database.
- Once a Product is added to the system, the ProductID cannot be edited. The ProductName and IsActive fields can be edited. The database will handle UpdateDate and UpdatedBy.
- The UI screen for Product maintenance, where admins add and update Products, will show a list of all Products and all fields from the database.
- The system will need a pick-list of active products, so that they can be added to, for example, an Order. The only fields visible in the UI for the pick-list would be ProductID and ProductName.
assume that from what I've gathered about DTOs, I'd need one for creating a product, one for updating a product, one for viewing all fields in the pick-list maintenance screen UI, and one for the pick-list itself. Is this accurate? Is there a simpler way using less DTOs? This is where I am lost on the topic.
EDIT: Just adding a comment, a lot of the DTO blog/articles seems to talk about the presentation layer, as it applies to DTOs, in terms of displaying data, and not about gathering data (user input) to send to the database.
EDIT 2: And about the Orders object, should it have a List(Of Product) DTOs? Which one of the many Product DTOs (that I think I need)? Should Orders not have a List(Of Product)? A List(Of ProductSummary) or other DTO?