Structura spațiilor de nume/soluții

Îmi cer scuze că am cerut o astfel de întrebare generalizată, dar este ceva care poate fi o provocare pentru mine. Echipa mea este pe cale să se angajeze într-un proiect amplu, care, sperăm, va trage împreună toate codurile aleatorii aleatoare care au evoluat de-a lungul anilor. Dat fiind faptul că acest proiect va acoperi standardizarea entităților logice din cadrul companiei ("Client", "Angajat"), sarcini mici, sarcini mari care controlează sarcinile mici și servicii de utilitate, mă străduiesc să găsesc cea mai bună modalitate de a structura namespaces și structura codului.

Deși cred că nu vă ofer suficient de multe detalii pentru a continua, aveți resurse sau sfaturi cu privire la modul în care puteți aborda în mod logic divizarea domeniilor dvs. ? În cazul în care vă ajută, cea mai mare parte a acestei funcționalități va fi dezvăluită prin intermediul serviciilor web și suntem un magazin Microsoft cu toate cele mai recente gadgeturi și gadget-uri.

  • Dezbatem o soluție masivă cu subproiecte pentru a face referințele mai ușoare, dar asta va face prea greu?
  • Ar trebui să închei funcționalitatea aplicațiilor vechi sau să las acea agnostic complet în spațiul de nume (de exemplu, o clasă OurCRMProduct.Customer față de o clasă generică Client )?
  • În cazul în care fiecare serviciu/proiect are propriile BAL și DAL sau ar trebui să fie un ansamblu complet separat?

Nu am experiență în ceea ce privește organizarea unor astfel de proiecte de anvergură, doar cu excepția cazului, așa că căut orice îndrumare pe care o pot obține.

0
fr hi bn

6 răspunsuri

Sfatul meu, după ce am angajat o întreprindere similară, nu este să agonizăm spațiile de nume.

Începeți să vă dezvoltați cu câteva linii directoare importante, pentru că oricum începeți, proiectul dvs. este organic și veți ajunge la reorganizarea spațiilor și claselor de nume în timp.

Nu pierdeți timpul vorbind prea mult despre proiectul dvs. Doar fa-o.

0
adăugat

Există un milion de modalități de a pielea o pisică. Cu toate acestea, cea mai simplă este întotdeauna cea mai bună. Care este calea cea mai simplă pentru tine? Depinde de cerințele dvs. Dar există câteva reguli generale de bază pe care le urmez.

În primul rând, reduceți cât mai mult posibil numărul total de proiecte. Când compilați de douăzeci de ori pe zi, acel minut suplimentar se adaugă.

Dacă aplicația dvs. este concepută pentru extensibilitate, vă recomandăm să vă despărțiți ansamblurile de-a lungul liniilor de proiectare vs. implementare. Plasați interfețele și clasele de bază într-o adunare publică. Creați un ansamblu pentru implementările din aceste clase ale companiei dvs.

Pentru aplicații mari, păstrați logica UI și logica de afaceri separate.

SIMPLIFICAȚI soluția. Dacă pare prea complexă, probabil că este. Combinați, reduceți.

0
adăugat

Soluțiile mari cu numeroase proiecte pot fi destul de greu de compilat, dar sunt mai ușor de gestionat împreună.

Am adesea unitati de testare unitar in aceeasi solutie ca si cele pe care le testeaza, pe masura ce tind sa le schimbi impreuna.

0
adăugat

Recent am experimentat exact același lucru la locul de muncă. O mulțime de cod ad-hoc care trebuia să fie structurat și organizat.

Este greu la început, din moment ce există atât de mult. Cred că cel mai bun sfat pe care l-aș putea da este să-i investesc timpul în vânt după o după-amiază vineri, pentru câteva săptămâni aș alege o aplicație/bucată de cod, acolo, gândiți-vă la ceea ce am putea face generic, copiați-o, puneți-o în noua bibliotecă oriunde credeam că ar trebui să fie. Odată ce am avut tot codul dintr-o aplicație migrată, aș lucra apoi la refacerea aplicației pentru a lucra din cadrul comun. Acest lucru a cauzat uneori probleme care trebuiau rezolvate, dar atâta timp cât nu a fost suficient de mare o afacere.

Piesa cu bucata, asta este singura modalitate de ao face.

În ceea ce privește structura, am încercat să imităm numărarea paragrafelor MS, deoarece cea mai mare parte este destul de logică (de exemplu, Company.Data , Company.Web , Company .Web.UI și așa mai departe.

Unul dintre avantajele majore este, probabil, eliminarea cantității de cod. Da, în aplicații era nevoie de puțină refactorizare, dar baza de cod este mult mai slabă și, în multe privințe, "mai inteligentă".

Un alt lucru pe care l-am observat este că aș avea adesea probleme în a încerca să-mi dau seama în cazul în care pentru a pune lucruri (în ceea ce privește namespacing), deoarece nu am fost sigur de ce a aparținut. Acum, acest lucru într-adevăr mă privește, am privit-o ca un miros rău. Din moment ce re-org totul se încadrează în spațiu mult mai frumos. Și cu codul specific de aplicație (acum foarte mic), ei se pun în Company.Applications.ApplicationName Acest lucru mă ajută să mă gândesc cu adevărat la obiecte de afaceri mult mai mult, deoarece nu vreau prea mult în acest spațiu de nume , așa că am venit cu modele mai flexibile.

Ne pare rău pentru postul lung .. Este un fel de rambling!

0
adăugat

Denumim ansamblurile în .NET în următorul mod Company.Project.XXXX.YYYY unde XXXX este Project și YYYYY este subproiect, de exemplu:

  • LCP.AdmCom.Common
  • LCP.AdmCom.BusinessObjects
  • LCP.AdmCom.Common.Dal

Luăm acest lucru dintr-un apel de carte Ghid de proiectare cadru de Krzysztof Cwalina (autor), Brad Abrams (autor)

0
adăugat

Pentru proiectele mari, abordarea pe care îmi place să o iau este să am un spațiu de nume de domeniu pentru obiectele afacerii mele și apoi să folosesc obiecte de transfer de date (DTO-uri) în straturile mele, unde este necesară stocarea și recuperarea obiectului de afaceri. Un DTO este un obiect simplu care nu conține nici o logică de afaceri.

Iată o legătură care explică un DTO:

http://martinfowler.com/eaaCatalog/dataTransferObject.html

0
adăugat