Poți cere unui AI să construiască o aplicație și să primești rapid formulare, pagini și un API care pare să funcționeze. Dar ce date trimite acel API? Primește un angajat doar informațiile necesare sau ajunge în browserul lui întregul profil al utilizatorului?
Acest ghid despre DTO cu AI pornește de la o situație simplă: aceeași aplicație este folosită de un manager și de un angajat, iar cele două roluri au nevoie de informații diferite. Vei înțelege ce face un DTO și, mai ales, ce să-i ceri concret lui Codex, Claude sau Grok pentru a obține o implementare potrivită proiectului tău.
Nu trebuie să memorezi definiții complicate. Trebuie să poți descrie cine cere informația, ce are voie să primească și cum vei verifica rezultatul.
DTO cu AI: ce trebuie să înțelegi înainte să scrii promptul
Ce înseamnă DTO, pe înțelesul tuturor?
DTO vine de la Data Transfer Object: un obiect folosit pentru transportul datelor între părți ale unui sistem. Într-un API, îl poți folosi pentru a descrie forma datelor primite sau trimise. Martin Fowler explică acest tipar ca pe un obiect care transportă date și poate fi transformat într-un format transmis prin rețea.
Imaginează-ți un dosar intern și două extrase pregătite din el. Dosarul este sursa informațiilor. Un extras conține trei câmpuri, altul cinci. Nu creezi doi utilizatori noi și nici două conturi. Pregătești două reprezentări ale informațiilor despre același utilizator.
Un DTO poate fi implementat ca o clasă, un record sau altă structură potrivită limbajului. Forma exactă depinde de proiect. Pentru început, contează lista câmpurilor pe care o definești.
Entitatea, DTO-ul și răspunsul API
În exemplul nostru, entitatea Utilizator este modelul intern cu care lucrează aplicația. DTO-ul descrie datele alese pentru un anumit schimb de informații. Răspunsul API este ceea ce primește efectiv clientul, de multe ori sub formă de JSON.
Aceste lucruri sunt legate, dar nu sunt identice. Un DTO trebuie folosit efectiv la construirea răspunsului; simpla existență a unei clase numite UserDTO nu schimbă automat datele trimise de API.
Exemplul simplu: un utilizator, două răspunsuri
Ce poate vedea angajatul și ce poate vedea managerul?
Să presupunem că dezvoltăm o aplicație internă. Stabilim următoarea regulă fictivă: angajatul își poate consulta propriul profil, iar managerul poate consulta profilurile membrilor echipei sale.
| Câmp | DTO pentru angajat | DTO pentru manager |
|---|---|---|
| ID | Da | Da |
| Nume | Da | Da |
| Adresă | Da, în acest exemplu | Da, în acest exemplu |
| E-mail profesional | Nu | Da |
| Departament | Nu | Da |
| Hash-ul parolei | Niciodată | Niciodată |
| Token de resetare a parolei | Niciodată | Niciodată |
Adresa apare pentru a păstra exemplul ușor de urmărit. În aplicația ta, include-o doar dacă funcția respectivă are nevoie de ea și politica de acces o permite. Rolul de manager nu oferă, prin definiție, acces la toate datele unei persoane.
De ce DTO-ul nu înlocuiește permisiunile?
Autorizarea stabilește dacă o persoană poate accesa o anumită resursă și anumite câmpuri. DTO-ul stabilește forma datelor pe care aplicația le transmite după aplicarea acestor reguli.
Un DTO cu trei câmpuri poate divulga informații dacă este trimis persoanei greșite. De exemplu, un angajat nu trebuie să poată citi profilul altui angajat doar schimbând ID-ul din adresă. OWASP descrie separat această problemă de autorizare la nivel de obiect.
Nici ascunderea unui câmp în interfață nu rezolvă problema. Dacă serverul îl trimite, el poate fi citit din răspunsul API. Recomandările OWASP despre accesul la proprietățile obiectelor cer selectarea explicită a datelor potrivite pentru destinatar.
Spune AI-ului ce construiești
Înlocuiește cererea vagă cu o situație concretă
„Fă-mi niște DTO-uri pentru utilizatori” lasă multe decizii nescrise. AI-ul nu știe dacă lucrezi la un director public, un panou intern sau o aplicație cu mai multe organizații. Nici numele clasei nu îi spune cine ar trebui să vadă adresele ori e-mailurile.
Începe cu scopul funcției:
Lucrez la o aplicație internă pentru o companie. Avem rolurile angajat și manager. Angajatul își consultă propriul profil. Managerul consultă profilurile membrilor echipei sale. Vreau răspunsuri API diferite pentru aceste situații, folosind DTO-uri sau mecanismul echivalent deja existent în proiect.
Acum cererea conține un rezultat observabil. Nu mai ceri doar un obiect de cod, ci un comportament al aplicației.
Oferă contextul proiectului
Cu acces la cod sau într-o conversație simplă
Dacă asistentul are acces la proiect, indică modulul relevant și cere-i să examineze implementarea existentă: modelul utilizatorului, rutele, autorizarea și testele apropiate de funcție. Dacă lucrezi într-un chat fără acces la fișiere, atașează fragmentele relevante, folosind date fictive.
Poți scrie:
Verifică mai întâi cum sunt construite răspunsurile API și permisiunile în acest proiect. Identifică fișierele relevante și urmează convențiile existente. Dacă nu ai acces la cod, spune-mi exact ce fragmente trebuie să-ți furnizez. Nu inventa structura aplicației.
Aceeași cerință se poate folosi în Codex, Claude sau Grok. Ce poate executa efectiv asistentul depinde de mediul și instrumentele disponibile. Un exemplu de cod oferit într-un chat nu înseamnă că proiectul tău a fost modificat ori testat.
Definește exact câmpurile permise
Scrie lista de includere
„Ascunde informațiile sensibile” este prea neclar. Pentru un proiect, e-mailul poate fi public; pentru altul, poate fi vizibil numai echipei. Spune care sunt câmpurile aprobate pentru fiecare răspuns.
Pentru răspunsul destinat angajatului, include exact: id, nume, adresă. Pentru răspunsul destinat managerului, include exact: id, nume, adresă, emailProfesional, departament. Adaptează denumirile la convențiile proiectului. Nu include alte proprietăți ale modelului intern.
O listă de includere te ajută să eviți o situație frecvent omisă: ulterior adaugi un câmp nou în model, iar acesta apare accidental în răspuns. În acest exemplu, noul câmp trebuie să rămână în afara contractului până când este aprobat explicit.
Cere un exemplu al rezultatului
Înainte de implementare, cere două exemple cu date fictive. Verifică dacă răspunsul pentru angajat are doar cele trei câmpuri, iar cel pentru manager doar cele cinci. Dacă AI-ul adaugă automat salariul, telefonul sau alte informații, corectează contractul înainte să continui.
Un exemplu mic face discuția mai clară decât o explicație lungă despre „date complete”.
Precizează regulile de acces
Cine cere datele și despre cine sunt datele?
Sunt două întrebări diferite. În exemplul nostru, un angajat autentificat poate cere propriul profil. Un manager poate cere profilul unui membru din echipa sa. Faptul că cineva este manager nu îi permite automat să citească profilurile din orice echipă.
Adaugă în prompt:
Determină identitatea și rolul solicitantului din mecanismul de autentificare verificat al aplicației. Verifică accesul la utilizatorul solicitat. Nu acorda drepturi pe baza unui parametru de rol primit de la client. Refuză accesul când regula nu permite citirea profilului.
Două endpointuri pot organiza clar funcția, dar numele lor nu acordă permisiuni. Un traseu care conține cuvântul „manager” are în continuare nevoie de verificarea accesului pe server. Dacă aplicația are deja o rută potrivită, nu este obligatoriu să creezi încă două.
Cere implementarea potrivită proiectului
Cum ajung datele în DTO?
Transformarea datelor interne în câmpurile răspunsului se numește adesea mapare. De exemplu, aplicația citește numele din model și îl pune în câmpul corespunzător al DTO-ului.
Poți cere două metode clare de mapare, una pentru fiecare contract. Nu transforma însă acest detaliu într-o regulă universală. Unele proiecte folosesc deja mappere, serializatoare sau alte mecanisme pentru răspunsuri. Important este ca selecția câmpurilor să fie explicită și verificabilă.
Implementează maparea explicită a câmpurilor aprobate. Integrează DTO-urile în răspunsurile reale ale API-ului și păstrează separarea existentă dintre autorizare, logica aplicației și construirea răspunsului. Evită introducerea unor biblioteci sau restructurări care nu sunt necesare acestei schimbări.
Separă citirea de modificarea datelor
Un profil returnat de API și un formular trimis către API nu au neapărat aceleași câmpuri. Faptul că cineva poate vedea departamentul nu înseamnă că îl poate modifica.
Dacă funcția include editarea profilului, cere un contract separat pentru intrare, cu validarea și autorizarea câmpurilor modificabile. Dacă lucrezi doar la citire, păstrează sarcina limitată la răspunsuri. Această delimitare ajută AI-ul să nu extindă inutil implementarea.
Cere verificări care pot demonstra rezultatul
Ce trebuie să dovedească testele?
În această funcție, testele utile verifică răspunsurile și regulile de acces, nu doar faptul că un DTO poate fi creat. Dă-i asistentului situații concrete:
- Angajatul își cere profilul și primește exact cele trei câmpuri aprobate.
- Angajatul cere profilul altei persoane și accesul este refuzat.
- Managerul cere profilul unui membru al echipei și primește exact cele cinci câmpuri aprobate.
- Managerul cere un profil din afara echipei și accesul este refuzat.
- O cerere neautentificată nu primește datele profilului.
- Modificarea unui parametru de rol din cerere nu oferă drepturi suplimentare.
- Hash-urile parolelor, tokenurile de resetare și câmpurile interne suplimentare lipsesc din răspunsuri.
Codurile HTTP și forma erorilor trebuie să respecte contractul proiectului. Nu cere un anumit cod doar pentru că apare într-un exemplu, dacă aplicația ta folosește intenționat alt comportament.
Cere dovezi despre verificările executate
Rulează verificările relevante disponibile în proiect. La final, spune ce comenzi ai executat, ce rezultate ai obținut și ce nu ai putut verifica. Dacă ai scris doar teste, fără să le rulezi, precizează acest lucru.
Un răspuns care spune „am adăugat testele” descrie o modificare. Un rezultat al execuției lor oferă o dovadă suplimentară. Ai nevoie să știi care dintre cele două s-a întâmplat.
Cere o explicație pe care o poți verifica
Cum citești rezultatul fără să fii expert?
După implementare, cere o explicație scurtă a traseului datelor: cine face cererea, unde se verifică drepturile, unde se aleg câmpurile și cum este construit răspunsul. Cere și fișierele modificate, împreună cu motivele schimbărilor.
Explică-mi implementarea în limbaj simplu. Arată unde este verificat accesul și unde sunt alese câmpurile returnate. Prezintă un exemplu pentru fiecare rol și indică testele care confirmă comportamentul. Menționează orice presupunere de business rămasă neconfirmată.
Dacă explicația nu corespunde exemplelor de răspuns, cere o revizuire punctuală. Nu este nevoie să înțelegi fiecare instrucțiune din cod pentru a observa că DTO-ul angajatului conține un câmp pe care nu l-ai aprobat.
Prompt complet pentru Codex, Claude sau Grok
Copiază și adaptează cerința
Înlocuiește regulile fictive cu regulile aplicației tale. Dacă nu ai decis cine poate vedea un anumit câmp, clarifică această decizie înainte să ceri implementarea.
Vreau să implementez răspunsuri API bazate pe DTO-uri pentru profilurile utilizatorilor din aplicația existentă.
Context: avem rolurile angajat și manager. Angajatul își poate consulta numai propriul profil. Managerul poate consulta profilurile membrilor echipei sale. Acestea sunt regulile funcției pe care o construim.
Contract pentru angajat: exact id, nume, adresă. Contract pentru manager: exact id, nume, adresă, emailProfesional, departament. Folosește denumirile echivalente din proiect. Parolele, hash-urile, tokenurile de resetare și alte date interne nu trebuie returnate.
Inspectează implementarea existentă și urmează convențiile proiectului. Dacă nu ai acces la fișiere, cere fragmentele necesare. Identifică autentificarea, autorizarea, modelul utilizatorului, construirea răspunsurilor și testele relevante.
Verifică pe server identitatea solicitantului, accesul la profilul cerut și câmpurile pe care le poate primi. Nu folosi un rol trimis de client pentru acordarea drepturilor. DTO-ul nu înlocuiește autorizarea.
Construiește explicit răspunsurile aprobate, folosind DTO-uri sau mecanismul echivalent existent. Integrează-le în endpointurile reale. Un câmp adăugat ulterior în model nu trebuie să apară automat în răspuns. Păstrează schimbarea limitată la această funcție.
Verifică prin teste răspunsurile pentru cele două roluri, accesul neautorizat la alte profiluri, cererile neautentificate, încercările de schimbare a rolului prin cerere și absența câmpurilor interne. Respectă formatul erorilor din proiect.
Dacă ai acces de lucru la proiect, implementează și rulează verificările relevante. Dacă poți oferi doar o propunere, spune asta explicit. La final, prezintă fișierele schimbate, exemplele de răspuns, rezultatele verificărilor și presupunerile care necesită o decizie din partea mea.
Cum continui conversația după primul rezultat?
Folosește observații concrete: „În răspunsul angajatului apare și e-mailul; elimină-l din contract și verifică testul aferent” este mai util decât „nu e bine”. Pentru o revizuire, poți cere: „Urmărește traseul real al răspunsului și verifică dacă există vreo cale care returnează direct modelul intern”.
Formula scop, context, reguli, exemple și verificări se poate aplica și rezervărilor, comenzilor sau facturilor. Contextul și criteriile clare apar în ghidul OpenAI pentru lucrul cu Codex, în recomandările Anthropic pentru Claude și în ghidul xAI pentru Grok. Promptul de mai sus este exemplul nostru de aplicare la DTO-uri.
Întrebări frecvente despre DTO-uri și AI
Trebuie să știu programare ca să cer DTO-uri unui AI?
Poți începe prin a defini rolurile, câmpurile și exemplele de răspuns. Pentru a evalua implementarea, ai nevoie de verificări și de cineva care poate revizui codul când schimbarea depășește nivelul tău de înțelegere.
DTO-ul este o nouă tabelă în baza de date?
Nu, crearea unui DTO nu înseamnă automat crearea unei tabele. El descrie date transportate. Nu cere migrarea bazei de date doar pentru că ai nevoie de un răspuns API diferit.
Sunt obligatorii două DTO-uri pentru două roluri?
Nu. Exemplul folosește două contracte pentru a face diferența vizibilă. Într-un proiect real, contractele pot fi organizate după funcție sau caz de utilizare, iar rolurile pot împărți același contract când regulile permit.
DTO-ul protejează singur informațiile?
Nu. Selecția datelor trebuie însoțită de autorizare. Verifică atât cine poate primi răspunsul, cât și ce informații conține acesta.
Pot folosi același prompt în Codex, Claude și Grok?
Da, cerințele de business rămân aceleași. Adaptează contextul oferit și solicitarea de execuție la accesul real al asistentului: conversație, fișiere atașate sau mediu conectat la proiect.
Ce fac dacă AI-ul spune că implementarea este gata?
Cere exemplele de răspuns și rezultatele verificărilor executate. Compară-le cu regulile tale. Un mesaj de confirmare nu înlocuiește verificarea comportamentului aplicației.
Începe cu datele pe care vrei să le trimiți
Pentru a lucra mai clar cu AI-ul, descrie întâi rezultatul: cine cere datele, ce profil poate consulta și ce câmpuri poate primi. Apoi cere implementarea și dovezile că respectă aceste reguli.
DTO-urile sunt un exemplu bun de lucru: o idee tehnică devine ușor de cerut atunci când o transformi în reguli concrete și rezultate pe care le poți verifica.