Ok, so we've seen that a DTO is just a Data Transfer Object, and a POCO is a Plain Old C# (or CLR) Object. These could be used a DDD Entities in an application, modeling the state and behavior of products within the system. As you can see from the comment, that private parameterless constructor is only there because Entity Framework needs it to instantiate the class when it is reading it from persistence.Īssume, for the sake of argument, that both of these Product classes include methods with behavior in addition to the constructors and properties shown. It is much more persistence ignorant than the previous example, but it's not entirely ignorant of persistence, since it has an otherwise useless private constructor declaration. It can be instantiated anywhere without difficulty. It doesn't have any tight coupling to static helpers. It doesn't require a base class, especially a base class in another library. This Product class is a POCO because it has no dependencies on third-party frameworks for behavior, especially persistence behavior. Instead, favor intention-revealing names like FooViewModel. Naming a class FooDTO gives no indication of how or where that type should be used in the application's architecture. Whenever possible, name your DTOs according to their intended use. And even in MVC apps, sometimes logic is added to ViewModels, such that they are no longer DTOs. So, it's important to consider the context before making any broad assumptions. You can't then conclude that all ViewModels are DTOs, since in MVVM architectures ViewModels typically include a great deal of behavior. Thus, in this scenario, a ViewModel is a specific kind of DTO.Ī ViewModel (used within MVC) is just a DTO with an intention-revealing name. These DTOs are typically called ViewModels, and ideally they should have no behavior, only data formatted as the View expects it. ![]() For instance, in most MVC architectures with Views that support binding to a data type, DTOs are used to pass and bind data to a View. In many architectures, DTOs can serve a number of roles. All it says is that an object consists only of data, not behavior. Thus, they do not break the "rule" stating that DTOs should contain no behavior. Such attributes do not add any behavior to the DTO itself, but rather facilitate behavior elsewhere in the system. It's not unusual to add metadata to a DTO in order to have it support model validation or similar purposes. ![]() What about attributes and data annotations? In C#, a DTO should only have properties, and those properties should only get and set data, not validate it or perform other operations on it. But wait, what is "logic" or "behavior"? Generally, logic and behavior refer to methods on the type. If a DTO contains logic, it is not a DTO. ![]() By definition, a DTO should only contain data, not logic or behavior. It's an object whose purpose is to transfer data. ![]() Data Transfer Object (DTO)Ī DTO is a "Data Transfer Object". So, what is the difference between a DTO and a POCO? First, let's define each term. Some developers use these terms interchangeably. Two terms that come up frequently when discussing software development in.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |