hankwr / Cmsc455Final

Backend for final project collaboration between CMSCs 106 and 455
2 stars 0 forks source link

RE: DTOs #1

Closed hankwr closed 3 months ago

hankwr commented 3 months ago

I've set up the DTO framework with in-object/out-object principles. The normal DTOs (or IDTOS), marked as DTO in their names, are intended for data input from the client, and won't have the fields to pass certain information to the database (eg. generated ID numbers, timestamps, etc.). The out-dtos (ODTOs), marked as such in their names, are likewise returned from the server to the client, and will hold more information in them. This should help with swagger-ui's documentation of http requests (I don't know how else to force swagger to document things in a certain way).I've set up the DTO framework with in-object/out-object principles. The normal DTOs (or IDTOS), marked as DTO in their names, are intended for data input from the client, and won't have the fields to pass certain information to the database (eg. generated ID numbers, timestamps, etc.). The out-dtos (ODTOs), marked as such in their names, are likewise returned from the server to the client, and will hold more information in them. This should help with swagger-ui's documentation of http requests (I don't know how else to force swagger to document things in a certain way).

I think it would work to have ODTOs be subclassed from their IDTO counterparts, but I'm still a little hazy on this.

(This probably isn't what the issue function is usually intended for, but whatever it's just the two of us)

I think it would work to have ODTOs be subclassed from their IDTO counterparts, but I'm still a little hazy on this.

(This probably isn't what the issue function is usually intended for, but whatever it's just the two of us)

hankwr commented 3 months ago

Aight so since we should do the whole "echoing back objects"-thing with post requests, I've realized that separate DTOs, while interesting, probably isn't a good idea. Thankfully it shouldn't be an issue to strip out the ODTO framework I've set up and move the data over to the DTO counterparts.

I suppose since ODTOs extend DTOs, you could try

ResponseEntity<EntityODTO> foo(EntityDTO entity) {
    // pre-processing...
    entity = new EntityODTO();
    // post processing...
    return ResponseEntity.ok().body(entity);
}

but I'm not sure if that's really worth it for swagger-ui clarity. Also I might be completely messing up how polymorphism do be doin.

stuja16 commented 3 months ago

I'll switch it over to singular classes for now just so we can make the echoing back nice and easy.

I also removed the IDs that were in the ODTOs because I don't think we need those values now that we have authentication implemented.

stuja16 commented 3 months ago

Closing this issue