In primul rand salut. Urmaresc de ceva vreme topicurile de pe forum si m-au ajutat cu ceva idei pana acum.
lucrez ca junior C# pe WPF, iar marea mea provocare este lucrarea de licenta … pe care am ales sa o fac in Asp.Net Core 2 (Server Side - API) si Angular 5 (Client Side - Website). Mi-am luat un tutorial de pe udemy, am invatat destul de multe din el, dar am o problema la structurarea APIului (mai exact, nu imi place cea folosita de autorul tutorialului), si anume:
in tutorial se foloseste urmatoarea arhitectura :
Controllers (contine actiunile, requesturile din client)
Models (maparea bazei de date)
Dtos (tot un fel de model care lucreaza cu Db, apelate in Controllere)
Data (contine DataContext, IRepository si clase Repository (create, read, update, delete) )
Helpers (AutoMapper si alte clase ajutatoare)
Sincer, nu-mi place amestecatura din Data si Dtos, si as vrea sa le definesc mai bine, dar fara sa afectez performantele aplicatiei:
Controllers (actiunile)
Models (maparea)
Dtos
Core cu DbContext si urmatoarele subfoldere :
4a. Interfaces (IRepository)
4b. Data (clasele ce implementeaza interfetele, cu operatiile CRUD in DB)
Utils cu clase ajutatoare
De fapt… daca ma uit bine, nu e mare diferenta, mai mult de redenumire. Doream sa scap de acel folder Dtos. Am cautat tipuri de arhitecturi inainte de a deschide acest topic, dar fara prea mare succes.
Eu am scris un api in WebApi 2 pt o aplicatie de la serviciu. Nu am folosit ierarhia de foldere implicita, ci mi-am facut eu una
Controllers
Models
Business(aici am pus interactiunea cu baza de date)
Poate nu este cea mai buna, dar pt complexitatea api-ului meu a fost suficent
Aici cineva a intrebat despre dto
Clasele DTO le-am folosit si eu in aplicatia de licenta.
Abordarea cu IRepository o vad in foarte multe tutoriale. De fapt cam in toate pe care le-am vazut pana acum
Inca ceva
Ia in considerare si cat de complex vrei sa fie api-ul.
Am reusit sa inteleg mai bine termenul de Repository, mai ales ca astazi am fost nevoit sa il implementez si la munca :))
cat despre arhitectura, a ramas :
Controllers
Models (imi pare ca cea mai mare utilizare a modelului a fost crearea tabelei in DB cu EF Migrations)
Core:
______/ Entities (am renuntat la denumirea de Dtos)
______/ Interfaces (IRepository / taskurile)
______/ Data (implementeaza Interfetele, metodele CRUD)
______/ DbContext.cs
Utils (liste, calcule, etc)
Asa, am reusit sa exclud accesul spre DB direct din Controller (si dinspre serviciile din partea client side, Angularul) si sa separ codul
Nu stiu daca ar fi bine sa folosesc sufixe in denumirea tuturor claselor (mai putin cele din Utils) pentru a sti clar la ce se refera fiecare, asa cum se intampla in controller (ex : AuthController). Pastrand aceasta specificatie as avea UserModel, UserForRegisterEntity, UserForLoginEntity, IUserRepository (in Interfaces) si UserRepository (in Data)
Incerc “sa-mi pastrez o regula” de scriere de la inceput, pentru a nu prinde vre-un obicei prost.