Za početak batali TableAdapter i Datasetove i preorijentiši se na EntityFramework. Mnogo je bolji od klasičnog ADO.NET-a.

E sad, što se tiče troslojne arhitekture. Tu imaš više različitih pristupa. Najbolje bi bilo da pogledaš malo po internetu na temu MVC, MVP... paterna, tj. uzora, ako ćemo srpski.

Kod MVC(Model-View-Controller) uzora se prave sledeći slojevi:
1. DataBroker - obezbeđuje pristup bazi podataka. Ovaj sloj bi trebao da bude potpuno nezavistan od modela i od vrste baze podataka
2. Model - čuva tranzijente podatke u toku rada aplikacije
3. Kontroler (Controller) - ovde se nalazi aplikaciona logika
4. GUI(View) - mislim da je ovo jasno.

Kod tebe su 2. i 3. sloj u okviru drugog sloja.

Inače postoji suptilna, ali bitna razlika između sloja(layer) i nivoa(tier).

U cemu se Entity Framework razlikuje od Enterprise library?

Nema potrebe da izdvajate EF, EF je zvanicno deo ADO.NET-a. Cak se i zvanicno zove "ADO.NET Entity Framework", isto tako ga ne bi gurao u svaku corbu jer nije mirodjija, ako ti ne treba nivo apstrakcije koju pruza mozes komotno i da ga zaobidjes (npr ako ti je model identican kao sema SQL Server baze komotno ti EF ne treba uopste)

1. To što on navodi inače se zove RecordSet arhitektura, i vjeruj mi, ništa joj ne fali za manje projekte bez jake domain logike. Napraviš generični DAL sa DataAdapterima, za koji je za novu tabelu dovoljno naslijediti generičku/abstraktnu klasu - te dodati mapping detalje kao naziv tabele, te nazivi kolona. Ako kontrolišeš obe strane (i bazu i app), onda je ovo super, jer svaki prim. ključ nazivaš Id itd... Pogledaj Fowler PoEAA za primjere.
2. MVC ne znam kako si ti zamislio, ali to je pattern prezentacijskog sloja, ne arhitekturalni pattern cijele aplikacije. MVC (i to čisti pravi MVC) se upotrebljava kod složene GUI logike, ili potrebe za izdvajanjem view-a (kao recimo u web-u što imaš). MVC varijacije (MVP, MVVM itd...) se lijepo uklapaju sa dosta prezentacijskih tehnologija kao Win/WebForms, WPF - XAML itd...
3. Ta diskusija tier vs layer malo ovdje nema smisla da se napominje - jasno je na šta on misli na logičke cjeline, a ne procese.

Entity Framework je ORM alat. Enterprise Library ima samo isto prvo slovo - E :) To je dodatni framework nad .NET-om za probleme tipičnog posovnog software-a. Imaš tu nekih dijelova koji bi se tako reći poklapali sa EF-ovom namjenom (kao Data Access Application Block), ali i drugih korisnih stvarčica (recimo Unity - dependency injection container) ...

OK. Ima situacija kada se mogu iskoristiti Data adapteri. Ali koliko sam ja do sada primetio, u svakoj ozbiljnoj situaciji sam imao problema sa njima. Zato ih i izbegavam. Možda sam ja radio nešto pogrešno, ali to su moja dosadašnja iskustva.


MVC nije patern prezentacijskog sloja, već arhitekturni patern. Pogledaj [url=http://en.wikipedia.org/wiki/Model–view–controller]Wikipediju[/url], a zatim i ostale resurse na netu i još par knjiga i videćeš da sam u pravu. Svrha MVC paterna je da obezbedi nezavisnost korisničkog interfejsa(view), modela i kontrolera, kako bi svaki mogao nezavisno da se razvija i testira. Na taj način se povećava fleksibilnost sistema.


Da, jasno je, ali treba biti precizan. Pogotovo što on to koristi kao sinonime. Zato sam i naglasio.

lonelyrider_44 kaže "drugi sloj (Business tier)", a sloj i tier su dve različite stvari. Očigledno je da tek ulazi u ove vode i bolje je da odmah raščisti šta je šta.

<sub>[Shadowed: Test oko pogresnog parsiranja url-a]

[Ovu poruku je menjao Shadowed dana 20.08.2010. u 15:30 GMT+1]</sub>

Ok, nek ostane razlika u mišljenjima, ali razmotri sljedeće - prezentacijski pattern je subset neke generalne arhitekturalne kategorije, i ono što ja hoću da kažem je da se on koristi primarno kod UI logike, s prvom namjenom smanjenja dependancy-a view-a od modela. Ako ga to ne kvalificira kao prezentacijski pattern, ne znam šta je onda? Šta će tebi biti model, to tu nije važno. Zamisli da radiš n-tier sistem sa višestukim consumerima (web, desktop, WCF endpoints, nevažno). MVC tu samo može biti pattern dizajniranja određenih consumer-a, nikako arhitekturalni pattern cijelog sistema. U manjim aplikacijama, i jednostavnijim sistemima (recimo većina web aplikacija) taj M u MVC je direktno i sam domain aplikacije (kojeg ustvari i nema, nego je tu eto samo da podrži komunikaciju sa bazom, najčešće preko ORM-a - i to Active Record verzije), pa možeš reći da je cijela aplikacija MVC.

MVC je nastao (i ostao) kao potpora za GUI framework-e. Kad već citiraš wiki, pogledaj drugu rečenicu:



S domain logikom ne završava aplikacija.


_{[Ovu poruku je menjao Sapphire dana 21.08.2010. u 02:12 GMT+1]}