This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by Vic
It is often necessary to transmit data from different entities within our code, anonymous (dynamic) objects destroy any possibility of debugging and therefore the best possibility is to create DTOs (Data Transfer Objects).
With the amount of data that must be transported, the amount of DTOs always grows and creates an environment where they become out of sync with the real models, probably due to a technical failure of the developer in the face of so many classes to take care of.
What are "fusion objects"?
In my terms (outside of any book, documentation or external article), "fusion objects" are entities that inherit from Tuple<T1, T2, T3...> and hides the Item1 and Item2 members allowing the developer to expose only the needed members while keeping a direct relationship with the reference entities.
Practical example
Let's suppose I have two entities in my database: UserAuthentication (which holds the user's authentication information, including sensitive data) and UserItems (which holds any kind of random item referring to that user).
class UserAutentication
{
public long Id { get; set; }
public long ItemsId { get; set; }
public string Username { get; set; }
public string Password { get; set; }
}
class UserItems
{
public long Id { get; set; }
public long UserId { get; set; }
public short ItemAQuantity { get; set; }
public short ItemBQuantity { get; set; }
}
Now, we have to find a way to get specific fields from these models in a presentable way to the final user - without exposing sensitive or useless data.
The common way is making a standard DTO model, like the example:
class UserSomeActionDTO
{
public string Username { get; set; }
public short ItemAQuantity { get; set; }
public short ItemBQuantity { get; set; }
}
Okay, it's great, isn't it? Just no. Now, let's suppose you need to change the UserAuthentication template or the UserItems. You will also have to change the DTO model directly as well as all your builds, following a difficult maintenance practice and attention issues that can occur frequently.
With "fusion objects" you can control the types that will compose the object explicitly as well as its quantity (if there are two, three or more types that will compose the DTO) and expose only the necessary fields in a safe way.
class UserSomeActionDTO : Tuple<UserAuthentication, UserItems>
{
//Constructor will call default tuple constructor
public UserSomeActionDTO(
UserAuthentication item1,
UserItems item2
) : base(item1, item2) {}
//We will overwrite "Item1" and "Item2" field to make them private
private new readonly UserAuthentication Item1;
private new readonly UserItems Item2;
//Now we can expose only the needed fields to that object
public string Username
{
get => Item1.Username;
}
public short ItemAQuantity
{
get => Item2.ItemAQuantity;
}
public short ItemBQuantity
{
get => Item2.ItemBQuantity;
}
}
Now, we can simple instance this DTO calling new UserSomeActionDTO(myUserAuthentication, myUserItems).
This content originally appeared on DEV Community 👩‍💻👨‍💻 and was authored by Vic
Vic | Sciencx (2022-09-25T16:11:13+00:00) Creating smarter DTOs with fusion objects in C#. Retrieved from https://www.scien.cx/2022/09/25/creating-smarter-dtos-with-fusion-objects-in-c/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.