[ hashtag @ 13.09.2011. 21:05 ] @
Imam jednu nedoumicu, pa molim sve one sa vise iskustva da mi razjasne neke stvari. Ako imam viseslojnu aplikaciju u .NET (DAL,BL i View) uz koriscenje Data readera i pozivanje stored procedura. Nije mi jasno kako pravite objekte? Npr. ako imam procedure za User-a (Insert,Update,Select,SelectByCountry). Da li procedure mapirate u objekte, pa tako za svaku proceduru imamo po jedan objekat ili za se sve to radi praveci samo jedan objekat? Sta se desava ako je na primer ime kolone userID u svakoj od procedura napisano drugacije (userID,userId,UserId...)?
[ pl4stik @ 14.09.2011. 11:33 ] @
N-Tier Application Patterns with Entity Framework

How Do I Use DataSets in an N-Tier Application?

To su ti kao neki best practices ...
[ Vreljanski Milan @ 16.10.2011. 13:45 ] @
E slusaj,

sve ovo je super, mislim ono tiers i to sto su nas ucili, ali ako ti ne lezi logici nemozes da skontas nikad... uf aj da ne
Citat:
Poruka sadrži neprimerenu reč ("s...m"), molimo da preformulišete izraz i pošaljete poruku ponovo. PIŠITE KVALITETNO I OZBILJNO!


skini DENKI-SQL programcic.

on ti za bazu napravi sve sp-e i napravi ti sve klase u kodu sa svim mogucim upitima, naravno onim generalnim insert update select... onda instanciras klasu "ImeTabele" i mozes da joj radis sta oceeees! sve je under the hud, konekcija i sve, sve, tako da ni o cemu ne mislis a imas sav kod da lepo pregledas.

to ti mozda nije lose da vidis otprilike kako bi mogla da izgleda primenjena ta "skolska" arhitektura.

ono na sta bih ti ja iz licnog iskustva skrenuo paznju je da cela prica sa arhitekturom pada u vodu, kada provalis da u jednoj stored proceduri mozes da odradis brdo stvari vezanih za aplikaciju.

nekako, jako je bitno dobro odraditi bazu, zatim ja nikad nisam uspeo da BL razdvojim u potpunosti od DAL-a, uvek uslede malo vremena za planiranje... uprskam stvar.

poenta, ne opterecuj se previse, sedi i cukaj i sve ce samo doci.

poz
[ ravni @ 16.10.2011. 20:05 ] @
Citat:
Vreljanski Milan: sve ovo je super, mislim ono tiers i to sto su nas ucili
tiers != layers
Citat:
... cela prica sa arhitekturom pada u vodu, kada provalis da u jednoj stored proceduri mozes da odradis brdo stvari vezanih za aplikaciju.
dobra praksa je u bazi drzati podatke, a programski kod u aplikaciji

da odgovorim na pitanje sa pocetka. Mislim da ti je rad sa data readerima, pored svih ostalih mogucnosti, nekako nekomforan. Imas na raspolaganju Typed datasets, EntityFramework, Linq2Sql, NHibernate, Simple.Data, Dapper... ipak je ovo 2011. godina.
[ hashtag @ 16.10.2011. 21:45 ] @
Znam da je rad sa readerom prevazidjen, ali takva nam je arhitektura, i tako se radilo do sada na projektu. Posto nemam dovoljno iskustva, a imam zelju da i volju da uspostavim neki svoj nacin rada, onda moram da kopam po netu sta i kako mogu da poboljsam. Otuda i ovo pitanje. A posto je situacija sada malo jasnija, molim jos jedan krug odgovora i preporuka. Da li nastaviti sa readerom, ili za nove funkcionalnosti implementirati nesto drugo? Da li je moguce, sada, kada je projekat vec u odmakloj fazi razvoja iskoristiti EF?
[ pl4stik @ 16.10.2011. 21:49 ] @
Citat:
hashtag:  Da li je moguce, sada, kada je projekat vec u odmakloj fazi razvoja iskoristiti EF?


Naravno da je moguce, a po meni je i jako pozeljno...
[ Boris B. @ 17.10.2011. 09:15 ] @
Citat:
ravni
dobra praksa je u bazi drzati podatke, a programski kod u aplikaciji
...
Imas na raspolaganju Typed datasets, EntityFramework, Linq2Sql, NHibernate, Simple.Data, Dapper... ipak je ovo 2011. godina.


Iako se obično slažem sa tobom, ovaj put mislim da nije sve baš tako jednostavno. Prvo, mislim da dobra aplikacija (N-tier ili neopravdano potcenjeni fat clienti) ima data consistency na svim nivoima, znači npr. pažljivo postavljeni uniqe keyovi i check constraints u samoj bazi koji čuvaju od eventualnih grešaka u BL, stored procedure za kritične, atomične operacije, itd... ipak postoje stvari koje jedino možeš na bazi da uradiš efikasno i kako treba, iako je 2011 :) . Po meni je baza sa svime što omogućava integralan deo aplikacije, a ne samo data storage. Iako ORM maperi kao EF ili NH omogućavaju persistance-ignorance, ignorisati mogućnosti baze i koristiti sve popularnije code-first principe je po meni greška.
[ mmix @ 17.10.2011. 14:02 ] @
Jos da neko to javi MSu Mada kazu da je u EF4.1 konacno ubacen DML support. Jel neko probao?
[ ravni @ 18.10.2011. 11:16 ] @
Citat:
Boris B.: Iako se obično slažem sa tobom, ovaj put mislim da nije sve baš tako jednostavno. Prvo, mislim da dobra aplikacija (N-tier ili neopravdano potcenjeni fat clienti) ima data consistency na svim nivoima, znači npr. pažljivo postavljeni uniqe keyovi i check constraints u samoj bazi koji čuvaju od eventualnih grešaka u BL, stored procedure za kritične, atomične operacije, itd... ipak postoje stvari koje jedino možeš na bazi da uradiš efikasno i kako treba, iako je 2011 :) .
ja sa ovim nemam problem. zasmetalo mi je sledece
Citat:
ono na sta bih ti ja iz licnog iskustva skrenuo paznju je da cela prica sa arhitekturom pada u vodu, kada provalis da u jednoj stored proceduri mozes da odradis brdo stvari vezanih za aplikaciju.
sto je potpuno pogresno. uvek se aplikacija moze 'naterati' da radi, problem se moze resiti na raznim mestima, ali je pozeljno stati i promisliti koju vrednost to donosi naruciocu na kraci i duzi rok i da li je pametnije uloziti malo vise vremena sada u dobru arhitekturu da bi se kasnije to visestruko isplatilo kroz lakse odrzavanje

i da odgovorim na pitanje
Citat:
Da li nastaviti sa readerom, ili za nove funkcionalnosti implementirati nesto drugo? Da li je moguce, sada, kada je projekat vec u odmakloj fazi razvoja iskoristiti EF?
Posto projekat vec postoji, cini mi se da je za tebe najlakse da probas da iskoristis spomenuti Dapper za nove stvari koje radis jer lightweight, pa se moze lako uglaviti