The sounds of code

La ricerca di pattern e procedure (pattern and practices , mm mi ricorda qualcosa) per sviluppare rapidamente e in modo robusto applicazioni orientate ai dati con Wpf . L' architettura : M-V- VM risolvere: Bisogna arginare la proliferazione del codice attraverso gli strati. Accesso ai dati: Entity Framework DTO usare i data transfert object solo per comunicazione fra componenti dislocate fra i servizi o anche per la comunicazione fra uno strato e l'altro? Dto flat o strutturati? Poco o DTO ? DI: Unity per iniziare, forse più semplice di MEF (non è richiesta la risoluzione runtime delle dipendenze) Pattern& Practices ? coì a prima vista sembra un carrozzone di un sacco di codice difficilmente attaccabile, vederemo... Dove cominciare? Secondo me il tutorial fondamentale è questo di Karl Shifflett . Il tutorial è disponibile come extension di VS2010, codice e tutorial integrati in un'unico progetto VisualStudio . In quattro iterazioni di uno stesso prog...

Alcune note concettuali importanti per disinnescare DI. Servono tutte.

MEF ( Managed Extensibility framework ) MEF è abbondantemente usato da VS2010 ( Plugin ) MEF è in incluso nel framework Un video introduttivo da channle 9 cosa risolve MEF Plugin ( and composite application ) Decoupling Application Partitioning (download on demand ) Third Party Extensibility Il consiglio del video: se si ricorre periodicamente nel risolvere uno dei problemi sopra indicati MEF può essere d'aiuto. Se il decouplig , l' IoC non sono un problema centrale (o i partecipanti al progetto non già orientati o nemmeno sono disposti a fare un salto mentale per capire quanto decoupling e Ioc siano importanti per la manutenibilità di un progetto) allora è meglio abbandonare MEF . Per cosa non usare assolutamente MEF : come ORM (non ho capito dal video se fosse una battuta o meno, in ogni caso è meglio non farlo).

Ci lanceremo mai verso IoC? IoC su msdn , come al solito una riproposizione di quanto scritto da Martin Fowler nel 2004 (lettura consigliata). Per ora direi di no, il succo del discorso di fowler è che DI introduce complessità aggiuntiva ripagata solo in contesti in cui molti team lavorano sullo stesso progetto e condividono lo stesso motore di Dependency Injection, nel caso di sviluppo piccolo team e progetto non mastodontico non vale la pena. Per il prossimo progetto mobile ci accontenteremo di un sano e semplice Resource Locator. Rimane comunque affascinante l'idea di IoC su Compact Framework di Chris Tacke . Magari un giorno...