0

This question keeps popping out every time I create a new Solution.

I would like to separate the Request Object, Database Entity and Response Object. If your Web API handles few entities I agree that it is not necessary to separate them. But what if I have the following requirements:

  1. Request Objects (api payload) has:

    • FirstName
    • LastName
    • BirthDate

  2. Database Entities (table) has:

    • Id
    • FirstName
    • LastName
    • BirthDate
    • CreateDate (for audit)
    • CreateBy (for audit)
    • UpdateDate (for audit)
    • UpdateBy (for audit)

  3. Response Objects (api body) has:

    • Id
    • FirstName
    • LastName
    • BirthDate
    • Age (calculated, readonly)

(Questions) > so with this idea in mind:

  1. Does it make sense to create separate classes for each type of objects?
  2. What naming convention can i use?
  3. Is there already a best practice to handle this different kind of objects?
  4. Is it fine to just use the suffixes Request, Entity, Response for each type of objects?

Reply are greatly appreciated!

imnotaduck
  • 177
  • 1
  • 12
VJPPaz
  • 917
  • 7
  • 21
  • I hope this will help you. https://code-maze.com/aspnetcore-webapi-best-practices/ or https://github.com/interagent/http-api-design or https://github.com/WhiteHouse/api-standards or https://fullstackmark.com/post/18/building-aspnet-core-web-apis-with-clean-architecture – Sanjay Bathre Sep 10 '19 at 10:17

2 Answers2

0

I hope i can awnser your questions as good as possible!

  1. Yes it does make sense to make an object of every entity.
  2. You can put it in a folder called "Model"
  3. You can look at MVC api's: MVC API
  4. Not sure
boudewijn
  • 29
  • 4
0

1 - Does it make sense to create separate classes for each type of objects? No. You can use one model and different mappers, it's make more sense than handle with different models about the same subject

2 - What naming convention can i use? It's depends on the name's convention your company is using.

3 - Is there already a best practice to handle this different kind of objects? Yes, you can use mapper pattern to map each different input/output: Repository and Data Mapper pattern

Also, this article can help with a good architectural standard: https://www.infoq.com/articles/advanced-architecture-aspnet-core/

4 - Is it fine to just use the suffixes Request, Entity, Response for each type of objects? It is depends on the name's convention again, but it is possible.

Tiago Vaccari
  • 1,116
  • 7
  • 16
  • for this ```1 - Does it make sense to create separate classes for each type of objects? You can use one model and different mappers.``` the answer is yes and no. it makes sense if you want to separate your code as command and queries for example. you don't need the full model to perform an operation like insert for example. – imnotaduck Sep 10 '19 at 10:33
  • @mr.szc81, you are right. The answer is no. It's make more sense it's make more sense than handle with different models about the same subject. – Tiago Vaccari Sep 10 '19 at 10:47
  • @TiagoVaccari you mean 1 model for all layers? isn't that dirty? i mean i don't need the Age, Create and Update fields but they are mentioned in my payload. i don't want to display the create and update to my response but they will be included in my response model. i'm using Swagger to document my Endpoint btw, i forgot to mention it. thank you for links btw – VJPPaz Sep 10 '19 at 11:01
  • @VJPPaz, I mean 1 model to represent the datasource (table), but you can create different "viewmodels" or mappers to deal with it, (eg. Age as a calculated field). So, You call the method passing the viewmodel instead the model class. – Tiago Vaccari Sep 10 '19 at 11:05
  • @TiagoVaccari that means you're answer is "YES". I'll create separate classes for each type of objects. c# class, 1 class for table, 1 class for resquest and 1 class for response. then just use mapper to map each properties. – VJPPaz Sep 11 '19 at 02:14
  • @TiagoVaccari my company doesn't have any naming convention yet, the only thing i am sure is that i can use suffixes. i guess i'll just use the suffixes i mentioned if there is no ideal suffixes that are often used. – VJPPaz Sep 11 '19 at 02:15