I have a model and a partial model which contains only the properties that I need to expose in JSON.
But the properties between the model and his partial model are redundant.
How can I avoid that or improve my approach?
namespace Dashboard.Models.UserModels
{
public class UserModel
{
public int id { get; set; }
public string dbName { get; set; }
public string firstname { get; set; }
public string lastname { get; set; }
public int idExternal { get; set; }
public int idInstance { get; set; }
public string login { get; set; }
public string password { get; set; }
public DateTime? dtContractStart { get; set; }
public DateTime? dtContractEnd { get; set; }
public string emailPro { get; set; }
public string emailPerso { get; set; }
public LuccaUserModel()
{
idInstance = -1;
}
// partial model for json result
// not sure is the best way or have to be here
public class PartialUserModel
{
public int id { get; set; }
public string firstname { get; set; }
public string lastname { get; set; }
public string emailPro { get; set; }
public string emailPerso { get; set; }
public DateTime? dtContractStart { get; set; }
public DateTime? dtContractEnd { get; set; }
public string url { get; set; }
}
// UserModel Methods
}
}
You can rename PartialUserModel UserModelBase class (or leave it as is... it just makes better logical sense to do so) and make UserModel to inherit from it:
public class UserModel : UserModelBase
{
...
}
Of course you'll need to remove all duplicate properties from UserModel in this case.
It's a thin line between doing a proper design and building an overkill design. Answer depends on many inputs, among which I chose to have project and model breadth most important.
In hope to have my answer clearer, I have to say I use different terminology. Data which is adopted for use in UI is usually called ViewModel. In your case, you would build UserViewModel which contains necessary subset of information.
If I'm working on a one-off project, I'll reuse model as a ViewModel. I'll do this by having helper method which removes sensitive information, loads up or cuts off data which is lazy loaded from database and does other preparation on data. All this is done with same model class.
If it's not a short term project, I look to create separate ViewModel classes which I map from model data. Then, if I'm working with mostly flat data I use AutoMapper tool to have data automatically copied, instead of writing my own mappers.
As another answer here states, you write a basic class with data you need in UI and extend it with other model data, however this is not a good approach for several reasons.
If violates separation of concerns. Project dealing with model and persistance should not know about your ViewModel
You may need to flatten data from related objects into ViewModel objects. In that case, your model objects would have fields which should not be there, or would be redundant.
You may need calculated fields and helper methods in ViewModel which would again end up in model, confusing everyone that is not updated about design.
You could want to adopt several unrelated model classes to same ViewModel class
To try and put it shortly, either reuse model class or create ViewModels. There is unfortunately no clever solution. If you find one, please post a comment as I'd like to hear about it :)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I have an Article entity in my database:
public class Article
{
public Guid Id { get; set; }
public string Heading { get; set; }
public string Author { get; set; }
public string Content { get; set; }
public DateTime CreatedOn { get; set; }
public DateTime UpdatedOn { get; set; }
public int ViewsCount { get; set; }
public ImageData Image { get; set; }
public IEnumerable<Comment> Comments { get; set; }
}
For the creation I have ArticleInputModel, and for displaying the details view, I have ArticleDetailsModel, and for update I have ArticleUpdateModel (etc....)
However those models have the same properties.
Should I separate this much if it means repetitions of code?
I try to follow SRP but this seems like is breaking DRY principle?
Am I overlooking something and what?
Should I separate this much if it means repetitions of code?
Usually, you can identify three situations with potentially different sets of properties when working with model classes (Data Transfer Objects; DTOs) for a single entity:
entity creation
entity reading (displaying, viewing)
entity updating
However, there may be many more subtypes — e.g. different ways to create or update an entity, partial vs. full update, various kinds of displays, e.g. full view, some kind of partial views, view of an entity in a list etc.
It does make sense to have a system in constructing DTOs, such that you differentiate between the create, read (view), update DTOs in respect to your Create, Read, Update operations. You can see a clear parallel between such DTOs and CRU(D) operations (there's typically no DTO for the Delete operation).
Regardless of the particular naming you use, such categorizations help future maintainability of your code: if, in the future, you need to introduce a property that may not be set during entity creation, but can be altered during an update, or vice versa, it is easy to do without extensive changes to unrelated parts of code, e.g. you change the updating path only, but avoid changing the creating path.
I try to follow SRP but this seems like is breaking DRY principle?
Providing the model (DTOs) classes are semantically different, then I don't see this as a violation of DRY. However, this may be subjective.
Think of DTOs as secondary objects. The primary declaration is the database entity, which is part of your data model. The various views of such an entity in the form of DTOs are dependent on this entity declaration. As long as you keep it to a simple public SomeType PropName { get; set; } in the DTOs, it is not a violation of DRY you couldn't live with. In addition, it makes sense to e.g. keep comments explaining various properties in entity declarations only, and not duplicate them into DTOs (unless you have to generate some API docs, but that's solvable with <inheritdoc/> as well). What's important, is the clear distinction between entities and DTOs and their roles.
If you're creating a new instance of an Article, what is it's Id?
Or as a more clear example, what will it's UpdatedOn date be?
How do you update something that doesn't exist yet?
One other issue you might come across very quickly is how are you going to return a list of all the articles by a particular Author?
In the Article table you should be storing Author as an Id linking as a foreign key to the Author table (assuming there can only be a single Author).
If your article table now looks like this...
public class Article
{
public Guid Id { get; set; }
public string Heading { get; set; }
public Id Author { get; set; }
public string Content { get; set; }
public DateTime CreatedOn { get; set; }
public DateTime UpdatedOn { get; set; }
public int ViewsCount { get; set; }
public ImageData Image { get; set; }
public IEnumerable<Comment> Comments { get; set; }
}
...you might begin to see where separate ViewModels/DTOs come into play.
Create
public class CreateArticle
{
public string Heading { get; set; }
public IEnumerable { get; set; }
public string Content { get; set; }
public string Image { get; set; }
}
You're creating a new Article so will probably be inserting an auto generated Guid as the key. You'll also be fairly likely to be taking the current date/time as the CreatedOn date. Author would come from a lookup list of some description so you'd need to pass some sort of list into the View (simplified as IEnumerable above). The image is most likely going to be supplied from a path to the image location so you'd maybe want to display as a text box.
Add
public class AddArticle
{
public string Heading { get; set; }
public Id Author { get; set; }
public string Content { get; set; }
public ImageData Image { get; set; }
}
When you've filled in your Create form, you now want to add it to the db. In this case your DTO needs to add data in the format the db expects. So you'd now be passing the selected Author Id and maybe the ImageData after some processing magic elsewhere.
You still don't need an Article Id or CreatedOn as these will be added once this DTO has validated.
Details and View
Hopefully you're now seeing the slight differences that make the ViewModel a valuable asset. You might also require something like the following to show the details of an Article as opposed to viewing the Article itself:
public class DetailOfArticle
{
public Guid Id { get; set; }
public string Heading { get; set; }
public Author Author { get; set; }
public string Content { get; set; }
public string CreatedOn { get; set; }
public string UpdatedOn { get; set; }
public int ViewsCount { get; set; }
}
public class ViewArticle
{
public Guid Id { get; set; }
public string Heading { get; set; }
public string Author { get; set; }
public string Content { get; set; }
public string CreatedOn { get; set; }
public string UpdatedOn { get; set; }
public int ViewsCount { get; set; }
public ImageData Image { get; set; }
public IEnumerable<Comment> Comments { get; set; }
}
Notice that the details might pass in an Author entity so that you can supply more information (this could also be exploded out into separate properties). You might also want to pass the date (and/or time) as a string after formatting etc.
The Article detail probably wouldn't need the comments as it's essentially the meta-data about the Article whereas the Article view is the Article as you'd want to present it for reading.
I am making ASP.NET core MVC project. In one Solution I have some assemblies - .Data, .Services, .Web. In the .Data there are the Models (for the database), DbContext, Migration etc. For the models I use DataAnnotations, but when there are some "magic" numbers like 100 (for the maximum length of the "Name" property) I prefer to use constants.
For example [MaxLength(CourseConstants.NameMaxLength)]. These constants I can use them in the ".Web" assemblie. For example when someone is making a course and I can restrict the maximum length of the name using the same constant like in the "Course" model.
So my question is - where to put the constants ? One way is in the separate class (example - "CourseConstants"). But I think that for better cohesion I should put the constants that are used for the "Course" model inside the "Course" class. And if I need them in ".Services" or in ".Web" I should call them from the Course class - example Course.NameMaxLength.
P.S. sorry if I dont follow some of the rules in this site and community, its my first question here.
CASE 1:
public class Course
{
public int Id { get; set; }
[Required]
[MaxLength(CourseConstants.NameMaxLength)]
public string Name { get; set; }
[Required]
[MaxLength(CourseConstants.DescriptionMaxlenght)]
public string Description { get; set; }
public DateTime StartDate { get; set; }
public DateTime EndDate { get; set; }
[Required]
public User Trainer { get; set; }
public string TrainerId { get; set; }
}
public class CourseConstants
{
public const int NameMaxLength = 100;
public const int DescriptionMaxlenght = 200;
}
CASE 2:
public class Course
{
public const string NameMaxLength = 100;
public const string DescriptionMaxlenght= 200;
public int Id { get; set; }
[Required]
[MaxLength(NameMaxLength)]
public string Name { get; set; }
[Required]
[MaxLength(DescriptionMaxlenght)]
public string Description { get; set; }
public DateTime StartDate { get; set; }
public DateTime EndDate { get; set; }
[Required]
public User Trainer { get; set; }
public string TrainerId { get; set; }
}
A common reason to separate models in a different project is that you might want to reuse them for other applications. For example you have an API and it returns some models in JSON format and you would want to use the exact same model in an application that consumes that API, since it's the same. Even better, when someone changes the class, it gets updated in your app as well.
Your question, though, relates to data models used inside the data access layer. These models should only be used in your business classes and, of course, in the DAL. They should not be reusable outside the scope of the DAL and projects that access data. If you want to make them consumable from the outside, you would map them to API models that would be different classes than EF classes.
That said, constants should be part of the DAL project, together with the EF data classes, since they should not be reused anywhere else. The only reason why you would put them somewhere else would be as an assembly to share between projects with constants like PersonNameLength or EmailLength or something like that.
As my domain classes I have Person and FavoritePerson classes as follows.
public class CompanyPerson : ICompanyPerson
{
[Key]
public Guid PersonId { get; set; }
public string Title { get; set; }
public string Description { get; set; }
}
public class CompanyFavoritePerson : IFavoritePerson
{
[Key]
public Guid FavoritePersonId { get; set; }
[Column(TypeName = "datetime2")]
public DateTime CreateDate { get; set; }
public Guid? CompanyPerson_PersonId { get; set; }
[StringLength(128)]
public string CompanyUser_UserId { get; set; }
public virtual CompanyPerson CompanyPerson { get; set; }
public virtual CompanyUser CompanyUser { get; set; }
}
In my web application I will need to show List of Favorite Person. So my view model is like this;
public class FavoritePersonViewModel
{
public Guid FavoritePersonId { get; set; }
public DateTime CreateDate { get; set; }
public Guid? CompanyPerson_PersonId { get; set; }
public string CompanyUser_UserId { get; set; }
//Option1: PersonViewModel PersonViewModel {get; set; }
//Option2: public string Title {get;set;}
}
Since I need to show Title of the favorite user in the list (where title belongs to Person class) which way will match with best practices?
Referencing a viewModel from another viewModel or extend viewModel with required extra attributes and fill them in business layer?
After some more research on this topic; I found out at this question
What is ViewModel in MVC?
it is clearly stated that:
View models can combine values from different database entities.
As like below;
So now you have data from the Employees and Departments tables in one
view model. You will just then need to add the following two
properties to your view model and populate it with data:
public int DepartmentId { get; set; }
public IEnumerable<Department> Departments { get; set; }
So I am going with Option 2.
The ViewModel pattern is just one of many patterns that fall into the 'Separated Presentation Pattern' bucket.
It's very important that you think about the requirements of your view before designing the ViewModel. For instance, if you have two widgets in your view and every widget has its own ViewModel, composite ViewModel is suitable in the situation, but if the view is just one that uses multiple domain classes, whether you have View model for each one, composite ViewModel is not suitable because it increases the complexity and every change in one ViewModel can break your code.
Thus, based upon your question
As my domain classes I have Person and FavoritePerson classes.
Since I need to show Title of the favorite user in the list (where title belongs to Person class).
It seems to me that composite ViewModel is not a good choice and you should design a new ViewModel.
It is also worth to read the ViewModel Best Practices
1) I want to know what is the recommended way to create & return a DTO for an object which has 10 attributes and I only want to return 2 with my DTO object.
2) Should DTO's have their own namespace ? If yes, how do we organize them ? Each DTO inside a single class file or all DTO's inside a single class ?
Please provide me some sample code.
DTOs are dumb objects composed of public getters/setters. I generally put them in a separate namespace called SomeProject.Dto.
public class CustomerDto {
public int Id { get; set; }
public string Name { get; set; }
public LocationDto HomeAddress { get; set; }
}
I generally try to keep the property names the same between the DTO and corresponding domain class, possibly with some flattening. For example, my Customer might have an Address object, but my DTO might have that flattened to:
public class CustomerDto {
public int Id { get; set; }
public string Name { get; set; }
public string HomeStreet { get; set; }
public string HomeCity { get; set; }
public string HomeProvince { get; set; }
public string HomeCountry { get; set; }
public string HomePostalCode { get; set; }
}
You can dramatically reduce the amount of repetitive mapping code of translating domain objects into DTOs by using Jimmy Bogard's AutoMapper.
http://automapper.codeplex.com/
Your question is very open ended. The answers are dependent on the scale of your application.
In general I create my DTO's or ViewModels in their own assembly. To get my DTO's I have some service layer take care of creating them based on my request.
If you want concrete examples take a look at some of the Asp.NET MVC examples at asp.net. While you may not be using MVC you can at least see how the ViewModels are created.
I have an MVC2 n-tier application (DAL, Domain, Service, MVC web) using a DDD approach (Domain Driven Design), having a Domain Model with repositories. My service layer uses a Request/Response pattern, in which the Request and Response objects contain DTO's (Data Transfer Objects) to marshal data from one layer to the next, and the mapping is done via help from AutoMapper. My question is this: what shape should a DTO typically take? Can it have nested/complex DTO's as well or should it strictly be a flat projection? Or possibly a mixture of both? Also, what are the main reasons for having a flat DTO vs a more complex/nested DTO?
For instance, suppose I had a domain such as the following:
public class Employee
{
public string FirstName { get; set; }
public string LastName { get; set; }
public Company Company { get; set; }
}
public class Company
{
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string State { get; set; }
}
There are three different ways I've thought of modeling the Response object.
Option 1 - the DRYest option:
public class GetEmployeeResponse
{
public class EmployeeDTO { get; set; } // contains a CompanyDTO property
}
From the research I've done, it would be inappropriate for a DTO to take a similar shape as the domain object(s) as demonstrated above.
Option 2 - a flattened projection of the domain (anti-DRY):
public class GetEmployeeResponse
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string CompanyName { get; set; }
public string CompanyAddress { get; set; }
public string CompanyCity { get; set; }
public string CompanyState { get; set; }
}
This is more simple, like a DTO apparently should be, but ultimately makes for more DTOs.
Option 3 - a mixture of both:
public class GetEmployeeResponse
{
public EmployeeDTO Employee { get; set; }
public CompanyDTO Company { get; set; }
}
This allows for the code to be a little bit more dry, reusable and manageable, and doesn't expose my domain structure to the end user. The other main benefit is that other responses, like GetCompanyResponse could simply return CompanyDTO, without having to make a copy of all those properties, similar to option 2. What do you think? Which option of these (if any) have you taken and/or have worked for you? If these Request/Responses later get exposed as WCF service methods, does your answer change?
My personal preference would be to try and keep it flat as possible with only the required data being transfered. having said that I have used deeply nested DTO in the past because it made sense at the time and fitted the requirements. so I guess it comes down to "it depends". At the end of the day go with what makes sense for the application at hand. No point trying to shoe horn data into a DTO convention that doesn't fit what you are tying to achieve.