Arhitekturu projektujes prema specifikaciji zahteva tvoje aplikacije .

Paterni koje si nabrojao (Command, Proxy, Singleton) ne postoje da bih ih primenjivao u globalu ,
vec sluze da ih "prepoznas" i primenis prema toj zadanoj specifikaciji
i na osnovu modela ponasanja same aplikacije tj. sistema.

Da bih dobio neki smisleni odgovor ,
moras malo opisati sistem koji pravis pre nego sto primenis bilo sta od ovog .

Nista posebno samo hocu da napravim mali projekat, a da iskoristim najbolje postavljenu arhitekturu da olaksa odrzavanje cele aplikacije. Cilj mi je da naucim kako da pravilno postavim projekat. Dakle za sada samo jednostavan CRUD (sa kompleksnim temeljima :) ).
Aplikacije koje sam do sada pravio su uglavnom bile "front end". I za arhitekturu sam korisio iskljucivo MVC.
E sada u .NET-u me buni DAL, da li on sluzi samo za cupanje podataka ili sluzi i kao storage dok traje sesija. Recimo aplikacije koje sam ja radio imale su MVC gde je u modelu bio proxy/singleton pattern u kome su bili svi podaci od trenutka kada se korisnik uloguje dok iz nje ne izadje, dakle taj deo mi je sluzio i za cupanje podataka i za cuvanje podataka.
Ako bih krenuo tom logikom u .NET-u, napravio bih WinForm projekat koji bi bio GUI layer koji bi imao svoju MVC postavku. Dakle Forme kao interfejs, za svaku formu njihov mediator, command za sve akcije, proxy za poziv BL layer-u, BL salje poziv DAL-u da uzme podatak sa servera, DAL vraca novi podatak u BL pa na GUI pravo u model ...

Ajde recimo sistem za knjizaru ovo je neka moja pretpostavka kako da postavim projekat:

I opcija:

-TomePit
+TomePit.GUI -
+TomePit.BL -
+TomePit.DAL - Samo za "pristup" podacima
+TomePit.DT - Value Objects
+TomePit.Common - Singleton klase koje bi drzale podatke kada se recimo korisnik uloguje ili kada se knjige prikazuju, znaci ovde bih drzao podatke

II opcija:

-TomePit
+TomePit.GUI - Model-View-Controller - podaci koji bi gore bili u common-u ovde bi bili u "Model-u"
+TomePit.BL -
+TomePit.DAL - Samo za "pristup" podacima
+TomePit.DT - Value Objects

Ne razumem jel postavljam neko lose pitanje? Zanima me kako drugi odrzavaju dobru strukturu svojih projekata :( .

Ja ovo ništa ne razumem. Skraćenice koje se spominju meni ništa ne znače (osim GUI). Jedini moj savet koji ovde može da upali je prosto probaj pa vidi sam šta ti odgovara. Verovatno je svaki pristup dovoljno dobar. Verovatno svaki pristup ima mane koje sada ne možeš da vidiš/pojmiš. Verovatno ćeš imati nekakvih gličeva u implementaciji, koji god pristup da odabereš. Tako da je poprilično svejedno šta ćeš odabrati.

Pa arhitekturno ti si vec odabrao kombinaciju MVC/three-tier, ti ustvari pitas kako da organizujes projekte u okviru te arhitekture a za to ne postoji magican fit-all odgovor i zato ti niko ni ne odgovara.

Za ostalo, nemoj da se oslanjas na singletone kao concurrency mehanizam za podatke, to je losa praksa i vec sam negde naveo da pruza laznu sigurnost (sta cemo sa drugom instancom programa). Da le ce podaci biti skroz offline, da li ce se kesirati u BLu ili ce svaki pristup zahtevati refresh, to zavisi od use-case-a, ne od globalne arhitekture. Nigde ti nije zabranjeno da kombinujes pristupe.

I malo prosiri svoje vidike, kontam da je MVC danas mantra i da se stavlja u sve od hello world aplikacije do sarmi, ali nije jedini arhitekturni patern koji postoji.

ljudi se previše zamaraju s teoriom... počni radit, i usavršavaj sam sebbe, s vremenom će ti samo doći