.
Anmeldung | Registrieren | Hilfe

.NET-Blogs Archiv Dezember 2007

JCQ auf CodePlex

27.12.2007 12:20:41 | Jan-Cornelius Molnar

Vor einiger Zeit habe ich begonnen, einen Icq Client in Visual Basic zu schreiben. Angefangen mit .NET 1.1 bin ich nun bei .NET 3.5 und einer WPF Oberfläche angekommen.

Die Basisfunktionen des Icq Netzwerks sind implementiert, man kann also problemlos einloggen, chatten, user suchen, user adden.

image image image

Die Oberfläche ist leider noch etwas umständlich und unvollständig. Nun suche ich weitere Personen, die sich für das Projekt interessieren und sich im OSCAR Protokoll und/oder WPF auskennen.

Das Projekt ist seit gestern Abend auf CodePlex verfügbar. http://www.codeplex.com/JCQ

LINQ To Everything

27.12.2007 12:10:50 | Jan-Cornelius Molnar

Das .NET Framework 3.5 bringt mit den Spracherweiterungen für C# 3.0 und VB 9.0 ein neues Feature namens Language INtegrated Queries (LINQ). Dadruch können beliebige Abfragen als streng typisierter Ausdruck in VB/C# etc. formuliert werden, dannach werden sie von einem Provider übersetzt gegebenenfalls optimiert und an die Datenquelle gesendet.

Das .NET Framework 3.5 bietet Unterstützung für die Datenquellen

  • Datenbanken wie Sql Server 2005 (Linq To Sql, Linq To Entities)
  • Xml (Linq To Xml)
  • .NET Objekte (Linq To Objects)

Microsoft hat aber viel dafür getan, das LINQ möglichst offen und flexibel zu gestallten, damit man leicht eigene Provider erstellen kann. Und dies zeigt bereits eine enorme Wirkung, denn auf CodePlex gibt es bereits zahlreiche weitere Provider

Neben diesen Projekten will ich noch drei weitere erwähnen

Slinq erweitert LINQ um den Zugriff auf Stream Daten (http://www.codeplex.com/Slinq)

InterLINQ implementiert einen n-Tier Ansatz für Linq To Sql (http://www.codeplex.com/interlinq)

NLINQ hat sich zum Ziel gesetzt Linq für Visual Studio 2003 und 2005 zur Verfügung zu stellen (http://www.codeplex.com/nlinq)

Dell Precision M90, Vista x64 und 4GB RAM

27.12.2007 02:04:24 | Jan-Cornelius Molnar

Da die Speicherpreise gerade so niedrig wie nie sind, habe mich noch kurz vor Weihnachten dazu entschlossen, meinem Dell Precision M90 4GB RAM zu spendieren. Die 4GB Problematik bei 32-bit Betriebssystem war mir bekannt, aber da ich ja stolzer Besitzer von Vista x64 bin, dachte ich, man könnte das einfach ignorieren.

Falsch gedacht, denn das M90 hat einen Intel i945 PM Chipsatz, der leider nur einen 32-bit Adressraum hat. Der Chipsatz kann also nicht mehr als 4GB addressieren. Da noch 512 MB für die Grafikkarte und ein paar MB für sonstige Optionen wie BIOS caching etc. reserviert sind, bleiben 3326MB für die Speicheradressierung auch bei Vista 64-bit.

Es bleiben bei mir also ca. 700mb ungenutzt, das ist aber immernoch besser als nur 2gb.

image

Expression Blend Service Pack 1

23.12.2007 12:36:56 | Jan-Cornelius Molnar

Soeben ist das SP1 für Expression Blend erschienen. Neben Stabilitätsverbesserungen enthält das Update auch eine verbesserte Unterstützung für Visual Studio 2008. Man muss also nicht unbedingt auf Blend 2 warten, um auch Visual Studio 2008 nutzen zu können.

Detaillierte Informationen zum Service Pack gibts hier
http://support.microsoft.com/kb/944811/en-us

Eine Liste mit behobenen Fehlern hier
http://support.microsoft.com/kb/944809/en-us

Und schließlich das Update hier
http://www.microsoft.com/downloads/details.aspx?FamilyID=A07196D1-971B-4710-99C8-D3D9603CCFCB&displaylang=en

Microsoft Download Center SILVERLIGHT (Preview)

22.12.2007 20:07:47 | Jan-Cornelius Molnar

Microsofts Download Center erlaubt den Zugriff auf zig-tausende Applikationen, Updates, AddIns, Whitepapers etc. Jeder Download ist zudem ausführlich dokumentiert und es werden Querverweise zu verwandten Downloads angeboten.

Um die Übersicht bei dieser Informationsfülle zu verbessern, testet Microsoft momentan eine durch Silverlight erweiterte Version des Download Centers (Preview: http://www.microsoft.com/beta/downloads/Default.aspx), die zahlreiche Erweitungen gegenüber der HTML Version bietet. Darunter auch eine verbesserte Performance, z.B. beim Sortieren von Listen nach Datum/Titel etc.

Es lohnt sich auf jeden Fall das neue Center einmal auszuprobieren!

Microsoft Expression Blend 2 December Preview

22.12.2007 20:03:35 | Jan-Cornelius Molnar

Nach der Erfolgreichen Einführung von Microsoft Expression Blend, geht das Designertool nun in die zweite Runde.

Der Schwerpunkt liegt hier ganz klar in der Unterstützung von Silverlight und Visual Studio 2008, es gibt aber eine ganze Reihe von Neuerungen.

Die aktuelle December Preview, sowie weitere Informationen erhält man hier:

http://www.microsoft.com/expression/products/download.aspx?key=blend2preview

Presenter First - MVP put into an agile process

12.12.2007 10:45:00 | Sebastian Jancke

Last time, I have tried to show, how do decouple the presentation layer. Today the topic or point of view is slightly different. The Model-View-Presenter patterns can be integrated as default construction of your presentation layer into your development process. Atomic Object has build a complete agile process around the MVP pattern, called "Presenter First". This process includes Test-Driven-Development (TDD), Story-Driven-Development and the MVP pattern.

The Model-View-Presenter pattern can be used to build domain logic and presenters based on the user stories, without a single line of UI code (or a single click). The views are all mocked out using a mocking framework (JMock, EasyMock, NMock, RhinoMock, ...). All domain logic and presentation logic is tested in isolation, the presenter comes first (well, before the view).

So I would see this process broken down into the following steps:

  1. Write a unit test, covering your user story in the domain layer
  2. Fulfill with domain code, until green
  3. Write a unit test for your presenter
  4. Fulfill with presenter code, until green
  5. Write an integrative unit test from the presenter down to the domain (at least you should)
  6. Now it's time to build some UI

My conclusion is, that the Model-View-Presenter pattern really decouples any UI concerns from the actual user stories and their presenter/domain implementation.

Technorati-Tags:

Reference Material: Atomic Object - Presenter First

Decoupling presentation logic with MVP

07.12.2007 01:55:00 | Sebastian Jancke

Motivation

Lot's as been written on decoupling presentation logic since the ages of Smalltalk and the MVC-Framework. But still today, even in medium sized projects (far beyond the stage of prototype), developers - and that's me also - tend to put far too much code into the UI layer. Simultaneous, details on validation and security constrains applied to the UI have mostly left out.

What's the problem?
The problems do not show up immediately, but after some time and growth. Most know, that putting domain logic into the UI layer is one of the worst habits. But few identify presentation logic in the UI-Implementation as a source of high coupling and low cohesion.

This is in conflict with one of the most basic rules of object oriented design principles: Subsystems should be highly cohesive and have low coupling. Some guys out there have a pretty short answer: "Using partial classes [in C#] decouples UI controls and logic". They fail to recognize, that partial classes in C# split a class across several files - but it does not bring in low coupling, as it is still one class.

Looking at the widespread known patterns discussed by the GoF, one can notice that there are couple of patterns with "Split Object" behavior: Decorator, Compositor, Proxy, Strategy, ...

What we need is a similar "Split Object" solution for decoupling of UI implementation and presentation logic concerns.

A possible solution
Since the ages of Smalltalk, we (should) know MVC - Model View Controller. It is a simple and working pattern for presentation logic decoupling. So why switching minds and using another one? What MVC fails, is to enable isolated unit testing. The guys of Atomic Objects noticed that [Atomic Objects Agile2006] and introduced the MVP - Model View Presenter pattern. Fowler has gone even further and split this pattern into two: Supervising Controller [Fowler EAA, SC] and Passive View [Fowler EAA, PV].

Passive View
Passive View reduces the UI (read: the views) to its absolute minimum. The difference to Model-View-Controller is that the view does not care about changes in the model. The presenter is in charge of updating the view with any changes in the model. Events on the view are subscribed by the presenter, views do not change the model.

As a direct result, all view logic lives in the presenter (sometimes also called controller, as this can be considered a MVC variant). The view and the model do not know of each other and have no direct reference.

Implementing it results in chatty interfaces between presenter and view, as all shown fields are transferred through properties on the view interface. I see it as an disadvantage, especially on complex objects. Supervising Controller can help, but it depends (as always) on your context.

A nice side effect is the following: Passive View makes it possible to implement views, that are totally unaware of your domain model. Splitting these layers into different subsystems (to be language and platform neutral) makes it physically nearly impossible to put business concerns into the views.

Supervising Controller
Passive View is a nice solution, as it fits our needs and decouples the presentation logic. Still it has some drawbacks. Data binding is the most important. Current view technologies have advanced support for (object) data binding. Using it can make your life a lot easier, writing less mapping code transferring values from and to the views.

Supervising Controller stands in. Presentation logic and command execution on view-events is still task of the presenter. Simple data mapping is done declaratively by the frameworks data binding. This solution lacks the ability to split view and presenter/model physically. Still it has the advantage of less code by using data binding.

Handling modal state
Presenters lack a concrete coupling to the view implementation. Unanswered is the task of showing model dialogs (Message Boxes) and asking the user for information (File selection, ...). Directly using message boxes in the presenter is generally a bad idea. It prevents us from isolated testing and worse: from testing at all.

A better approach is using the most valuable weapon in computer science - abstraction. We create a thin interface:

public interface IHumbleMessageBoxService
{
bool AskYesNoQuestion(string title, string message);
}
Our view subsystem implements this interface, for example with a standard message box. This service is injected into the presenter (follow up: Dependency Inversion), communication is only going through this interface. The presenter is unaware of the message box details, model dialogs, etc.

Using this approach now enables us to use unit testing again on our presenters. Generally everything should be decoupled by dependency inversion - it makes your testing life easy and your design more flexibly and explicit.

Validation
I consider validation as an integral part of the business logic. Complex validation rules regarding more than simple per-field checks are near to impossible to implement correctly in the UI (without high efforts). Those validation rules can be easily implemented in the domain model. Using current technology for declarative validation checks (Spring.Validation (Java, .NET) and MS Validation Block) make this task easy. Executing those checks should be initiated from the presenter, pushing the results (read: all at once) to the UI.

The habit of using the default "ErrorProvider" of .NET's Windows.Forms is a bad idea, because it locks the user to the current field, triggering errors. Complex validation rules require the presentation of all errors at once, thus triggering of the complete validation in the presenter is key. You may start to think, how popular "complex" rules are. The most "complex" rule one may think of is two date fields as input for a date range.

Further, there are several types of validation rules in a system. Some are part of your business requirements, but some are introduced by a certain persistence architecture(files, databases, ...). Not aggregating all types of rules in the domain layer results in wide spreading of validation concerns. Mediating validation and their results to the views is naturally placed in the presenter. No one (?) wants his UI layer to talk directly to services and operations of the domain layer.

Security
Securing operations on the domain layer is easily achieved with declarative and imperative security. Microsoft Security Block (Part of Enterprise library) is capable of both, using Aspects for this task can be easily implemented with Spring.Aop in Java and .NET. Currently this is the way, security is build into famous frameworks like JBoss Seam.

While it is acceptable for users of web applications to read "Operation not allowed", it is definitely not for rich desktop applications. I expect the same to happen in the field of AJAX enabled web applications. The question is: how can we prevent the user right in the UI layer from trying to execute certain operations?

In our domain model, we should have all operations available. Using declarative security is key here, because it clearly states security constrains at well defined,

Generically, we need to access these security attributes through reflection. For those in the .NET world and using Microsoft's IPrincipal:

bool roleMemberFlag = Thread.CurrentPrincipal.IsInRole("CanApproveClaims");

this is an easy task. It enables us to access security information for certain fields and operations via reflection. The presenter enables and disables the involved controls. Try doing that directly in your "code behind" of Dialogs, wihtout messing up all of your code.

Better design with higher effort?
Using the MVP pattern (and using patterns in general) rises the question of effort and results. In our case, testing presentation logic with unit testing the presenters in isolation is simpler and easier than any complex blackbox testing at the UI front.

Further, we gain more flexibility, code reuse and a design that meets object oriented principles. On the effort side, extracting an interface is of actually no cost, using today's refactoring support available.


Regeln | Impressum