Există motive negative pentru utilizarea unei soluții N-Tier?

Sunt destul de nou pentru compania mea (2 săptămâni) și începem o nouă platformă pentru sistemul nostru folosind .NET 3.5 Team Foundation de la DotNetNuke. "Arhitectul" nostru sugerează că folosim un proiect de clasă. Desigur, am înapoi cu o arhitectură "de trei niveluri" (Business, Data, proiecte de clasă Web).

Există dezavantaje în utilizarea acestei arhitecturi? Pro ar fi separarea codului de date, păstrarea obiectelor de clasă departe de codul dvs. etc.

0
fr hi bn

6 răspunsuri

Ca și în cazul în care orice abstractizare creează complexitate, astfel încât complexitatea realizării N-nivelului ar trebui să fie justificată în mod corespunzător, de exemplu, N-nivelul beneficiază de fapt sistemul? Acolo va fi sisteme mici care vor funcționa cel mai bine cu N-tiered, deși multe dintre ele nu vor.

De asemenea, chiar dacă sistemul dvs. este mic în acest moment, este posibil să doriți să adăugați mai multe funcții mai târziu - nu mergeți pe N-level ar putea să constituiți un fel de datorie tehnică din partea dvs. a avea grija.

0
adăugat

Cred că un dezavantaj destul de mare este că volumul suplimentar de cod pe care trebuie să-l scrieți, să-l administrați și să-l păstrați pentru un proiect mic poate fi doar prea mare.

Totul se limitează la ceea ce este potrivit pentru mărimea proiectului, durata de viață așteptată a proiectului final și a bugetului! Uneori, în timp ce faci lucrurile "în mod corespunzător" este atrăgătoare, a face ceva puțin mai "ușor" poate fi decizia comercială potrivită!

0
adăugat

M-aș împinge cu greu pentru abordarea pe n treaptă, chiar dacă este un mic proiect. Dacă utilizați un instrument ORM, cum ar fi codemith + nettiers, veți putea să configurați rapid proiectele și să dezvoltați coduri care vă rezolvă rapid problemele de afaceri.

Mă omoară când începeți un nou proiect și petreceți zile în jurul roților de rotire, vorbind despre modul în care trebuie să fie arhitect "arhitectura". Doriți să vă petreceți timpul rezolvând problema afacerii, nu rezolvând problemele pe care alte persoane le-au rezolvat pentru dvs. Folosirea unui ORM (nu contează cu adevărat care dintre ele, alegeți unul și lipiți-o) pentru a vă ajuta să obțineți tracțiunea inițială vă va ajuta să vă concentrați asupra obiectivelor proiectului și să nu vă distrageți încercările de a rezolva problemele legate de "arhitectură".

Dacă, la sfârșitul zilei, arhitectul dorește să urmeze abordarea cu un singur proiect, nu există niciun motiv pentru care nu puteți crea un dosar app_code cu un dosar BLL și DAL pentru a separa codul de acum înainte, ceea ce vă va ajuta să vă deplasați la Soluție N-tijă mai târziu.

0
adăugat

ea tinde să ia o echipă neexperimentată mai mult pentru a construi 3-tier.It e mai mult cod, deci mai multe bug-uri. Dar joc doar avocatul diavolului.

0
adăugat

Pentru că doriți ca capacitatea să puteți distribui straturile pe diferite niveluri fizice (întotdeauna folosesc "nivel" pentru fizic și "strat" ​​pentru logică), trebuie să vă gândiți de două ori înainte de a pune totul în o clasă pentru că aveți refactorizări majore de făcut dacă sau când trebuie să începeți să distribuiți.

0
adăugat

Singurul dezavantaj este complexitatea, dar cu adevărat cât de greu este adăugarea unor obiecte de domeniu și legarea la o listă a acestora, spre deosebire de utilizarea unui set de date. Nici măcar nu trebuie să creați trei proiecte separate, puteți să creați doar 3 foldere separate în cadrul aplicației web și să le dați fiecărui domeniu un nume, cum ar fi YourCompany.YourApp.Domain, YourCompany.YourApp.Data etc.

Marele avantaj îl reprezintă o soluție mai flexibilă. Dacă începeți să vă scrieți aplicația ca o aplicație bazată pe date, conectându-vă puternic paginile formularelor web la seturile de date, veți termina mult mai mult să migrați mai târziu la un model de domeniu central, deoarece logica dvs. de afaceri crește complexitatea.

Poate că pe termen scurt vă veți concentra pe o soluție simplă, creând obiecte de domeniu foarte simple și populându-le din seturi de date, puteți adăuga logica lor de afaceri după cum este necesar și puteți construi un ORM mai sofisticat după cum este necesar sau puteți folosi nhibernate.

0
adăugat