Este mai bine pentru a crea clase de model sau stick cu generic clasa de utilitate bază de date?

voturi
5

Avem o clasă de utilitate simplu, in-house pentru apelurile noastre de baze de date (un înveliș de lumină în jurul valorii de ADO.NET), dar mă gândesc de a crea clase pentru fiecare bază de date / obiect. Ar fi ceva inteligent pentru a face acest lucru, sau ar beneficia numai dacă am utilizat cadrul MVC complet pentru ASP.NET?

Deci avem acest lucru:

SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters);
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters);
SQLWrapper.Execute(connstr-alias, sql-statement, parameters);

Gândire de a face acest lucru:

Person p = Person.get(id);
p.fname = jon;
p.lname = smith;
p.Save();

sau pentru un nou record -

Person p = new Person();
p.fname = Jon;
p.lname = Smith;
p.Save();
p.Delete();

Ar fi acest lucru inteligent, sau ar fi nejustificată? Pot să văd beneficiul pentru reutilizare, schimbarea bazei de date și de întreținere / lizibilitatea.

Întrebat 05/08/2008 la 21:10
sursa de către utilizator
În alte limbi...                            


4 răspunsuri

voturi
8

Această întrebare este încărcat, date condus de design vs design condus de domeniu. Pentru orice aplicație care are o bună cantitate de comportament, atunci ar trebui să fie preferat de design condus de domeniu. Raportarea sau cererile de utilitate tind să funcționeze mai bine (sau sunt mai rapide pentru a dezvolta), cu un design bazate pe date.

Ceea ce ceri este „ar trebui compania mea face o schimbare fundamentală în modul în care codul nostru de design“. Ca un domeniu-ciudat, reacția mea intestin este să țipe da . Cu toate acestea, prin natura simplă a întrebării dumneavoastră, eu nu sunt sigur că ați înțeles pe deplin domeniul de aplicare al schimbării pe care o propune. Cred că ar trebui să vorbești mai mult pentru echipa ta despre asta.

Ia niște literatura de specialitate, cum ar fi DDD lui Evan carte, sau fundații electronică gratuită , iar apoi veți fi într - o poziție mai bună pentru a judeca ce direcție ar trebui să meargă.

Publicat 05/08/2008 la 21:28
sursa de către utilizator

voturi
2

Abordarea discuți este considerat unul bun de mulți populare, inclusiv pentru mine! Învățarea această abordare va necesita un oarecare efort, dar nu lasa ca te pune off!

Ce zici doar încearcă un mic proiect cu LINQ to SQL ? Poate găsiți un proiect de referință frumos pe Google Code , si de a studia modul în care alții au lucrat cu ea.

Este un instrument simplu, și vă va permite să vă familiarizați cu unele dintre problemele care apar cu obiecte de cartografiere la bazele de date.

Veți putea apoi să obține o simt pentru ea , și să decidă dacă este în valoare de curba de învățare.

Vor fi noi concepte pentru a înțelege și experimenta, lucruri cum ar fi:

  • Unitatea de lucru : Când executați Salvați și Delete , etc, un ORM tinde să nu facă acest lucru imediat, în timp ce o bază de recordset DAL voință. Acest lucru poate fi surprinzător astfel că va trebui să învețe un pic despre asta. Citiți pe unitatea de model de lucru pentru a obține o înțelegere a acestui.
  • Operațiunile în vrac sunt o problemă sau / M. Un cititor de date poate itera eficient prin mii de rânduri, dar cu un ORM trebuie să fie atenți atunci când se lucrează cu loturi mari de obiecte. Din nou, unul pentru a citi pe.
  • Asociații par mare atunci când se pot face chestii de genul , customer.Orders.Countdar ele sunt , de asemenea , cauza multor probleme. Veți avea nevoie pentru a găsi unele practici sigure de urmat atunci când se lucrează cu asociații.

...a numi câteva.

Pentru început, nu vă faceți griji cu privire la moștenire și lucruri, începe doar simplu și au entități simple, care se potrivesc la tabele.

Încercați să folosiți-le în același mod în care ați folosi DAL existent. Apoi, începe experimentarea cu asociațiile.

Atunci poate încerca punerea în mai mult comportamentul entităților dumneavoastră. Dacă începeți place acest lucru, și simt că aveți nevoie de mai multe caracteristici, ia în considerare a încerca o caracteristică-bogat ORM mai mult ca Lightspeed sau Nhibernate .

Sper că acest lucru vă ajută!

Publicat 03/10/2008 la 11:07
sursa de către utilizator

voturi
2

Prin nici un mijloc este MVC modelul de proiectare numai pentru web, dar este una utilă.

Adoptarea doar „M“ va plăti dividende, în opinia mea, chiar dacă nu se poate / nu va adopta „V“ sau „C“.

Publicat 05/08/2008 la 21:13
sursa de către utilizator

voturi
0

Mie mi se pare că încearcă să facă ceea ce LINQ poate face deja pentru tine. Dacă sunteți blocat într - un cadru mai vechi în care cant utilizați ca, i - ar putea sugera să utilizați Subconic ( http://subsonicproject.com/ ) în loc de a crea manual toate aceste obiecte model de mână.

Am avut un proiect în care am fost într-o situație similară și a fost schimbat la subsonic la jumătatea cu rezultate fantastice. Mai repede de dezvoltare și mult mai ușor de citit / cod de utilizare.

Publicat 26/09/2008 la 15:41
sursa de către utilizator

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more