Dosare sau proiecte într-o soluție Visual Studio?

De obicei, fac un proiect pentru GUI un proiect pentru logica de afaceri un proiect pentru accesul la date și un proiect pentru teste unitare.

Dar, uneori, este prudent să aveți separare pe bază de servicii (dacă utilizați o arhitectură orientată spre servicii) cum ar fi autentificarea, vânzările etc.

Cred că regula de degetul pe care am lucrat off este că, dacă o puteți vedea ca o componentă care are o separare clară a preocupărilor atunci un proiect diferit ar putea fi prudent. Dar aș crede că folderele versus proiectele ar putea fi doar o preferință sau o filosofie.

Eu personal simt că dacă codul reutilizabil este împărțit în proiecte, este mai simplu să folosești alte locuri decât dacă e doar în dosare.

Separarea elementelor în proiecte este adesea o optimizare a arhitecturii YAGNI. Cât de des ai reușit să folosiți acele proiecte separate, într-adevăr? Dacă nu este un eveniment frecvent, complicați dezvoltarea, construirea, desfășurarea și întreținerea pentru reutilizarea teoretică.

Prefer foarte mult separarea în foldere (folosind spații de nume adecvate) și refactorizarea pentru a separa proiectele atunci când aveți un caz de reutilizare în viața reală.

Separarea codului dvs. sursă în   mai multe proiecte au sens doar dacă   tu...   ... Mai mulți dezvoltatori implicați   și doriți să le tratați munca   consumabile negru. (nu foarte   recomandat) ...

De ce nu este recomandat acest lucru? Am descoperit că este o modalitate foarte utilă de a gestiona o aplicație cu mai multe discuri care lucrează pe diferite porțiuni. Efectuează checkins mult mai ușor, în principal prin eliminarea efectivă a fuzionărilor. Foarte rar, vor trebui să lucreze două proiecte în același timp în același timp.

Dacă faceți mai multe proiecte, asigurați-vă că toți cei care adaugă codul la soluție sunt pe deplin conștienți de intenția acestora și fac tot posibilul pentru a le înțelege dependențele dintre proiecte. Dacă ați încercat vreodată să rezolvați mizeria când cineva a plecat și ați adăugat referințe care nu ar fi trebuit să fie acolo și ați scăpat cu ea de câteva săptămâni veți înțelege acest punct

În mod implicit, întotdeauna trebuie doar să creați un folder nou în cadrul aceluiași proiect

• Veți obține o singură asamblare (fără gimnastică suplimentară ILMerge)
• Ușor de încurcat (pentru că veți avea mai puține tipuri și metode publice, în mod ideal deloc)

Separarea codului dvs. sursă în mai multe proiecte are sens numai dacă ...

• Au câteva porțiuni ale codului sursă care fac parte din proiect, dar nu pot fi implementate în mod implicit sau deloc (teste unitare, pluginuri suplimentare etc.)
• Mai mulți dezvoltatori implicați și doriți să tratați munca lor ca o cutie neagră consumabilă. (nu foarte recomandat)
• Dacă vă puteți separa în mod clar proiectul în straturi / module izolate și doriți să vă asigurați că nu pot consuma încrucișat membri intern . (de asemenea, nu este recomandat, deoarece va trebui să decideți care aspect este cel mai important)

Dacă credeți că unele porțiuni din codul dvs. sursă ar putea fi reutilizabile, nu creați încă un proiect nou. Asteptati pana cand veti dori sa o refolositi intr-o alta solutie si sa o izolati din proiectul original dupa cum este necesar. Programarea nu este lego, reutilizarea este, de obicei, foarte dificilă și adesea nu se va întâmpla așa cum a fost planificată.

denny a scris:

Eu personal simt că dacă codul reutilizabil este împărțit în proiecte, este mai simplu să folosești alte locuri decât dacă e doar în foldere.

Sunt cu adevărat de acord cu acest lucru - dacă îl puteți reutiliza, ar trebui să fie într-un proiect separat. Cu asta a spus, este, de asemenea, foarte dificil de reutilizare eficient :)

Aici, la SO, am încercat să fim foarte simpli cu trei proiecte:

• Proiectul MVC Web (care face o treabă plăcută de separare a straturilor în foldere în mod implicit)
• Proiect de baze de date pentru controlul sursă al DB noastre
• Teste de unitate împotriva modelelor / controlorilor MVC

Nu pot să vorbesc pentru toată lumea, dar sunt mulțumit de cât de simplu am păstrat-o - accelerează într-adevăr clădirile de-a lungul!

Chiar cred că este mai bine să împărțiți proiectul, dar totul depinde de mărimea proiectului și de numărul de persoane care lucrează la acesta.

Pentru proiecte mai mari, am un proiect pentru

• acces la date (modele)
• servicii
• capăt frontal
• teste

Am obținut modelul de la Rob Connery și aplicația de la magazin ... pare să funcționeze foarte bine.

mvc-storefront