❔ MVC app architecture which is consuming 3rd party API
I am developing a fresh MVC app, but because I usually maintain/upgrade existing app, I am not really sure how to approach this from the architecture perspective, so I won't make too big of a mess.
My solution is currently made out of 2 layers:
- UI Layer (controllers, viewmodel, resx translations)
- Data layer (Entities, dbContext, migrations, Services, IServices) - I am not sure if this is correct or if there is any benefit, having service (control database entity) and its interface in the same project?
And about the consuming 3rd party API - this app will partly work with Zebra FX7500 RFID reader, which is controlled over its API. How/Where would I put this RFID controlling logic? I would need a few methods for it - Authenticate, start, stop, ping,.. I would also have some DTOs, and I think thats it. Should I create another project inside the solution, something like "Reader management" (and if yes, what type would this be, and what else would I need)? Or should I put it somewhere in UI layer, since its not that complex?
Thanks for your help!
4 Replies
@reeeeeee I would have a service layer too.
The DAL would contain EF, your Models, and even the specific class that interacts with your RFID reader. The services would be on top of the DAL and would bridge everything together. This way you have no business logic in your UI layer.
So another project (like service/Core/Application), move my services and interfaces there, and also add communication with this Reader?
And in DAL, I would add the needed DTOs and stuff, related to reader?
In the case of the reader specifically, since you probably don't have both a DTO, and the equivalent of an Entity, I would put the DTOs there indeed.
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.