Vă mulțumim pentru susținere

Este mai bine să creați clase de modele sau să păstrați clasa utilitară generică a bazei de date?

Avem o clasă de utilitate simplă pentru apelurile de baze de date (un obiect de lumină în jurul ADO.NET), dar mă gândesc să creez clase pentru fiecare bază de date / obiect. Ar fi o chestie inteligentă, sau ar fi de folos numai dacă am fi folosit întregul cadru MVC 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ândirea 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 inteligent, sau ar fi prea mult? Văd avantajele pentru reutilizare, schimbarea bazei de date și întreținere / citire.

0
adăugat editat

4 răspunsuri

Pentru mine se pare că încerci să faci ceea ce LINQ poate face deja pentru tine. Dacă sunteți blocat într-un cadru mai vechi în care nu puteți folosi acest lucru, aș putea sugerează să utilizați Subconic ( http: // subsonicproject. com / ) în loc de a crea manual manual toate aceste obiecte de model.

Am avut un proiect în care eram într-o situație similară și m-am schimbat la subsonică la jumătatea drumului cu rezultate fantastice. Dezvoltare mai rapidă și mult mai ușor de citit / utilizat cod.

0
adăugat
Testez Linq la SQL când scriu asta, este minunat. Se pare că este pentru cartografiere simplă, dar ar trebui să fie suficient pentru tot ce am nevoie. Categoric ceva ce ar trebui generat.
adăugat autor Steve Tranby

Această întrebare este încărcată, bazată pe date, design versus design condus de domeniu. Pentru orice aplicație care are o bună cantitate de comportament, atunci ar trebui să fie preferată designul bazat pe domeniu. Aplicațiile de raportare sau de utilitate tind să funcționeze mai bine (sau să se dezvolte mai repede) cu design bazat pe date.

Ceea ce cereți este "dacă compania mea va face o schimbare fundamentală în modul în care proiectăm codul nostru". Ca un ciudat de domeniu, reacția mea intelectuală este de a țipa da . Cu toate acestea, prin natura simplă a întrebării dvs., nu sunt sigur că înțelegeți pe deplin domeniul de aplicare a modificării pe care o propuneți. Cred că ar trebui să vorbești mai mult cu echipa ta despre asta.

Obțineți o literatură, cum ar fi cartea Evan's DDD sau cărți gratuite pentru cărți electronice și apoi veți fi într-o poziție mai bună de a judeca în ce direcție ar trebui să mergeți.

0
adăugat
Mulțumesc pentru informații, mă voi uita în acele cărți. Îmi pare rău că întrebarea mea a fost încărcată / simplă. Nu am vrut să scriu prea mult și probabil că ar fi trebuit să fi întrebat despre Model vs. No-Model. Problema cu echipa mea este că eu sunt nou aici și ei rulează o grămadă de cod spart clasic-ASP sphagetti, plus că se dezvoltă în același mod în timp ce utilizează unele dintre caracteristicile ASP.Net. (anterior a răspuns acest răspuns ca răspuns, care a fost șters conform regulilor comunității)
adăugat autor Steve Tranby

MVC nu este singurul model de design pentru web, dar este unul util.

Adoptarea doar a "M" va plăti dividende, în opinia mea, chiar dacă nu puteți / nu va adopta "V" sau "C".

0
adăugat
Vă mulțumim pentru intrare, cred că voi începe să adăugați / înlocuiți "M" așa cum ați pus-o! (răspunsul anterior a fost răspuns, care a fost șters în conformitate cu regulile comunității)
adăugat autor Steve Tranby

Abordarea pe care o discuți este considerată una bună de mulți oameni, inclusiv eu! Învățarea acestei abordări va necesita un efort, dar nu lăsați asta să vă scape!

Ce zici doar de a încerca un proiect mic cu LINQ to SQL ? Poate că găsiți un proiect de referință frumos pe cod Google și studiați modul în care alții au lucrat cu el.

Este o unealtă simplă și vă va permite să vă familiarizați cu unele dintre problemele care vin cu cartografiere obiecte în baze de date.

Veți fi capabil să obțineți o simțire pentru el și să decideți dacă merită curba de învățare.

There will be new concepts to grasp and experiment with, things like:

  • Unit of Work: When you execute Save and Delete etc, an ORM tends to not do this immediately, whereas a recordset based DAL will. This can be surprising so you'll need to learn a bit about that. Read up on the Unit of Work pattern to get an understanding of this.
  • Bulk Operations are an issue with OR/M. A data reader can efficiently iterate through thousands of rows, but with an ORM you have to be careful when working with large batches of objects. Again, one to read up on.
  • Associations seem great when can do stuff like customer.Orders.Count but they are also the cause of many problems. You'll need to find some safe practices to follow when working with associations.

...a numi câteva.

Pentru început, nu vă faceți griji cu privire la moștenire și chestii, începeți simplu și aveți entități simple care se dau pe tabele.

Încercați să le utilizați în același mod în care ați utiliza DAL existent. Apoi începeți să experimentați cu asociații.

Apoi, probabil încercați să vă comportați mai mult în entitățile voastre. Dacă începeți să plătiți acest lucru și simțiți că aveți nevoie de mai multe funcții, luați în considerare încercarea unui ORM mai bogat în caracteristici, cum ar fi Lightspeed sau NHibernare .

Sper că acest lucru vă ajută!

0
adăugat