Data Class for data combined from Other Classes

[cjb110]

I'd like a bit of help with terminology/practices around models and DTO's. If it makes any difference to the answer, this is a blazor client/webapi server in C#, and there will be a database ORM (likely EF) at some point. I've got some simple plain object classes that I've been calling Models, and each of these contain the properties for one 'thing' in my application. Now one part of my UI wants to display data from multiple of these model classes. Now I'm pretty sure you don't want to get all of data from each model and combine on the UI. I'm also pretty sure I can't transfer an anonymous type over a webapi call? Or at least I couldn't easily work with it if I did. So I think I want to create a second class that has the properties from both the parent classes I want to use, the server part does the combining and transfers that class. So is this combined class more commonly referred to as a DTO? and that for ease of understanding I should separate that from my main model classes? Also if I do just want all the data from a model class, I dont need to create a seperate DTO just for that, and its ok to just reuse the model class? thanks

[Richard Deeming]

DTO stands for "data transfer object", so technically anything you return from your API will be a DTO. The problem with reusing model classes, particularly if you're using an ORM like Entity Framework, is the navigation properties. For example:

public class Customer
{
public List<Order> Orders { get; set; }
}

public class Order
{
public Customer Customer { get; set; }
public List<OrderLine> Lines { get; set; }
}

public class Product
{
public List<OrderLines> OrderLines { get; set; }
}

public class OrderLine
{
public Order Order { get; set; }
public Product Product { get; set; }
}

If you now want to return the details of a single order, that will include the customer, which will include all of the customer's orders. Unless your serializer can handle it, you already have a circular reference. But it gets worse: each order line will return the product. And each product will return all of the order lines which use it. And those will include the details of the order they're associated with, which will include all of the lines for that order. And each order will return the details of the customer, which will return all of the orders and order lines for that customer. Pretty soon, you're returning almost everything from your database just to display the details of a single order! It's usually better to create specific DTOs to represent just the data you want to return, with no circular dependencies. You can use a tool like AutoMapper[^] to simplify mapping between your model classes and your DTOs.

---

"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer

[Lost User]

A DTO (data transfer object) is like a pack animal; it's used to move data around as a convenience; they're not part of the "official" model. A DTO comes to mind (for example) when you have to pass "a lot of parameters"; a DTO class is tidier. It's said they shouldn't have methods, only data; but I see no reason not to have special getters, setters and the like if its convenient Your EF classes would be considered part of your official model; but a single class is not typically referred to as a model; "entity" maybe. Model data (entities) are typically stored (eg. in a db); DTO's aren't. And, yes, when you retrieve an entity from EF, you can use it "as is"; bearing in mind that these entities can be in different "states" (attached, detached, modified), depending on you requirements at the time. And your UI can have multiple / different entities (from different tables); eg. the classic "sales invoice" with header (entity1) and details (entity2); the parent-child relationship. And data typically gets passed in a web service as XML which you put together as you please (according to spec). see: Data Contracts.

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

[Mycroft Holmes]

And here is why some of us never use EF! I would normally create a model that reflects the data required by the view (sorry I'm WPF oriented), so a request for order details would populate only the order, item lines and customer details for the order requested and pass the single object to the client.

Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP

[Lost User]

FUD

It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

[cjb110]

I think the WPF model concept is where I was initially coming from, as that still seems a good idea for a Blazor wasm app. Even if the V/VM part is a little different. The webapi (or a service behind that) can do the translation between what I want to show and EF or any other database interaction.