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...)?
Pitanje u vezi arhitekture i kako vi to radite
Zaključano
Zakačeno
N-Tier Application Patterns with Entity Framework
How Do I Use DataSets in an N-Tier Application?
To su ti kao neki best practices ...
How Do I Use DataSets in an N-Tier Application?
To su ti kao neki best practices ...
Potpis
To sto nekoliko miliona ljudi tvrdi da nisi u pravu ne znaci da stvarno nisi - Frank Zappa
https://youtu.be/DLe358DPGXU
https://youtu.be/DLe358DPGXU
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
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
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
Potpis
***If there is a will, there is a way***
Citat:
Vreljanski Milan: sve ovo je super, mislim ono tiers i to sto su nas ucili
Citat:
... cela prica sa arhitekturom pada u vodu, kada provalis da u jednoj stored proceduri mozes da odradis brdo stvari vezanih za aplikaciju.
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.
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?
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...
Potpis
To sto nekoliko miliona ljudi tvrdi da nisi u pravu ne znaci da stvarno nisi - Frank Zappa
https://youtu.be/DLe358DPGXU
https://youtu.be/DLe358DPGXU
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.
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.
Potpis
if it walks like a duck and quacks like a duck, it could be a dragon doing a duck
impersonation.
impersonation.
Jos da neko to javi MSu
Mada kazu da je u EF4.1 konacno ubacen DML support. Jel neko probao?
Potpis
Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić
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 :) .
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.
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?