Planet XAML ~ Florian Krüsch's Blog on XAML, .NET, WPF and Silverlight

All Tags

all

english

deutsch

Architecture

Software Design and Architecture
- [Architecture architecture, TDD tdd]
  Unity, na endlich
  by Florian Krüsch, February 14, 2008
  
  Seit vorgestern ist unter dem Namen Unity eine CTP Version des "Dependency Injection Application Block" der Patterns & Practices verfügbar. Es ist zwar sicher noch zu früh, Castle Windsor dafür in die Ecke zu legen, aber es ist wie auch ASP.net MVC ein Zeichen dafür, dass die Technologie in eine gute Richtung geht. Inversion of Control bedeutet losere Kopplung, bessere Testbarkeit und Wartbarkeit.
  Interessant wird es insbesondere im Zusammenhang mit Prism, dem "WPF Composite Application Block" und der neuen Enterprise Library, die alle auf auf IoC aufsetzen. Pattern wie Model View Presenter lassen sich damit wesentlich eleganter in Anwendungen integrieren.
  cheers,
  Florian
  
  no comments
- [Architecture architecture]
  [Link] MVC vs MVP
  by Florian Krüsch, November 2, 2007
  
  Jeremy Miller erklärt in seinem Blog klar und knapp die Unterschiede zwischen Model-View-Controller und Model-View-Presenter im Zusammenhang mit verschiedenen .NET UI Technologien (WebForms, WinForms und Acropolis/WPF).
  Hier der Link:
  http://codebetter.com/blogs/jeremy.miller/archive/2007/10/31/ development-trivial-pursuit-the-difference-between-mvc-and-the-different-flavors-of-mvp.aspx
  
  1 comment
- [ASP.NET aspnet, Architecture architecture]
  Linq to SQL DataContext in a Windsor Lifestyle
  by Florian Krüsch, February 6, 2008
  
  Rick Strahl has a nice summary of the various options, in which scope to hold a Linq to SQL DataContext. The per request solutions is the logical choice. In the context of Domain Driven Design there might be another option, namely a DataContext per aggregate root, but this is another topic.
  A lot of code there... even though this is partly due to the fact that it attempts to work per thread or per web request in either case.
  Things get so much easier when you employ an inversion of control container. The DataContext becomes more or less an implementation detail of the repository interfaces and the per request lifecycle is just taken care of. Castle windsor and a little bit of configuration can realy help you get rid of a lot of boiler plate code here.
  
  castle.config
  <configuration> <components> <component id="repositoryProvider" type="Kruesch.Data.Repositories.LinqRepositoryProvider, Kruesch.Core" service="Kruesch.Services.IRepositoryProvider, Kruesch.Core" lifestyle="PerWebRequest" > <parameters> <connectionStringName>SiteDbConnection</connectionStringName> </parameters> </component> </components> </configuration>
  Be careful to dispose the DataContext at the end of the request in order to close the database connection:
  
  public class LinqRepositoryProvider : IRepositoryProvider, IDisposable { private DomainDataContext _dc; // c'tor public LinqRepositoryProvider(String connectionStringName) { String connectionString = ConfigurationManager.ConnectionStrings[connectionStringName].ConnectionString; _dc = CreateDataContext(connectionString); } ... // Factory method, provice a repository implementation public ISharedItemsRepository GetSharedItemsRepository() { return new SharedItemsRepository(_dc); } // DON'T FORGET THIS public void Dispose() { if (_dc != null) { _dc.Dispose(); _dc = null; } } }
  Cheers,
  Florian
  
  no comments
- [WPF wpf, Architecture architecture]
  WPF - DM-V-VM or M-V-P - WTF?
  by Florian Krüsch, October 25, 2007
  
  In the early days of WPF (they are over now, today is Silverlight), there was an app called Microsoft MAX that combined photo-gallery with an RSS reader and looked pretty neat.
  Dan Crevier, a member of the team at Microsoft, who build MAX, then went and described the underlying design pattern, which he called the DataModel-ViewModel-View pattern.
  You can read all about it here.
  It took a while until I realized that this is an incarnation of what Martin Fowler describes as PresentationModel.
  What's special about DM-VM-M is that View and ViewModel are glued together using DataBinding quite heavily. DataBinding is a very powerful concept in WPF and this is a nice way to do it.
  Basically what DM-VM-M gives you is something that is very close to the view, but separated and testable: a model of the view. The VM also contains the logic that talks to the data-model and that's why I would not choose to implement it for more complex types of apps.
  Instead, what I favor is a variation of the Supervising Controller Pattern, which Martin Fowler describes here.
  A Supervising Controller type Model-View-Presenter architecture fits very well with the powerful databinding machinerie of WPF and allows very good testability of the behavior of an application.
  Basically what you do it set the DataContext of the Window or the current view (UserControl) to the object model, so you can bind your data against it. You add Commands in XAML and expose the CanExecute and Executed events in the view interface. It makes sense to add a little bit of translation logic there that removes the Routed- aspect and casts the command parameter to type that's actually data-bound.
  e.g.
  
  IView
  interface IView { event EventHandler<CommandExecutedArgs<Item>> EditExecuted; event EventHandler<CommandCanExecuteArgs<Item>> CanExecuteEdit; void ShowEditDialog(); }
  
  Controller
  class SupervisingController { private IView _view; private IDataModel _model; // ... handle view events // ... handle data model events // ... tell view what to display // ... tell datamodel what to do }
  DM-M-VM does have its place, but it's not the only way to design WPF apps. In fact I would use DM-M-VM for simple apps where you want to maximize testing on the view. If there's a bit more logic involved, I'd go for a Supervising controller approach, where the view basically manages itself and the presenter encapsulates the logical behavior.
  cheers,
  Florian
  
  2 comments