Search results for 'app:weblogs' matching tag 'Patterns'

Prism and .NET RIA Services

NunoGodinho — Mon, 07 Sep 2009 05:00:00 GMT

Prism is a real interesting Guidance and was built for Silverlight 2.0, and some of the feedback I’ve received is if it works well with the new version 3.0, and so I remembered blogging about this.

The most usual questions are:

1. Does this work well with Silverlight 3 ?

Yes it works fine with this new version of Silverlight.

2. Does this work well with .NET RIA Services ?

Yes. They don’t only work well together, they actually complement each other, since one of the elements in the product backlog of the Prism Team was the access to server data, and since they didn’t had time to do this, .NET RIA Services can do this for them.

In order to know more about the subject read this David Hill’s post.

About how to have quick starts about Prism read this other David Hill’s post.

Silverlight 3 with MEF support

NunoGodinho — Thu, 30 Jul 2009 05:00:00 GMT

One of the things that I really thing would be important for Silverlight in order to make easier the Modularity of the Business applications developed in Silverlight, since the Prism approach is nice but I think that the MEF approach is simpler and so this should be a breakthrough for Silverlight Business Application Development.

After some talks with Brad Adams from Microsoft and also posting some feedback I came to this very interesting post of Brad that talks about how can we use the MEF for Silverlight that was made available on the CodePlex site related to MEF.

Brad make a very good example of the usage of MEF in this blog post.

So enjoy the reading and good coding.

Silverlight 3 related information’s

NunoGodinho — Wed, 29 Jul 2009 05:00:00 GMT

Silverlight 3 has been release and now we have also the Unit Testing Framework binaries here that will help making Unit Tests in our solutions when using Silverlight 3. More information’s here.

Also important is the release of Prism Visual Studio Templates that will help developers get using the Composite Application Guidance for WPF and Silverlight, and make what seems to be hard, simpler, and also with the new MVVM pattern available.

Download the Prism Visual Studio Templates here.

Update to the Prism Visual Studio Templates here.

More information about the Prism Visual Studio Templates here.

Interesting reading about Entity Framework 4.0

NunoGodinho — Mon, 06 Jul 2009 05:00:00 GMT

Entity Framework has suffered great changes and in order to know more about them I recommend the following reading:

POCO (Plain Old CLR Object or Persistence ) in the Entity Framework 4.0

Sneak Preview: Persistence Ignorance and POCO in Entity Framework 4.0
POCO in the Entity Framework:

“Why is POCO important in Entity Framework? Is important because now we have the ability to really separate the Storage Model from the Conceptual Model, and being the Conceptual Model our normal CLR Objects, that was not possible in previous versions of Entity Framework. This is a huge breakthrough for this 4.0 version. Is not perfect, and in this technologies it never is but it’s very interesting”

Part 1 - The Experience (Explains how to make this two parts of the POCO experience with Entity Framework 4.0, from making the Model to the designing of the POCO entities, as well as answering some interesting questions)
Part 2 – Complex Types, Deferred Loading and Explicit Loading (Goes further in the POCO entities and make changes shows how to implement Complex Types as well as configuring the Loading by using Deferred/Lazy Loading or Explicit Loading)
Part 3 – Change Tracking with POCO (Explains furthermore how the Change Tracking, that is so important in Entity Framework, works in POCO entities and how can it be configured by using Metadata)

Using Repository and Unit of Work patterns with Entity Framework 4.0 (Explains how to implement common patterns like Repository and Unit of Work using Entity Framework 4.0)
Entity Framework Feature CTP 1 (Announcement of the Entity Framework CTP Features for .NET 4.0 Beta 1)

Feature CTP Walkthrough: Self Tracking Entities for Entity Framework (Explains the scenarios on where to use the Self Tracking Entities)
Feature CTP Walkthrough: POCO Templates for Entity Framework (Explains how to use POCO Templates, that is a kind of T4 Template in order to generate POCO entities)
Feature CTP Walkthrough: Code Only for Entity Framework (Explains how to Entity Framework without any model like EDMX, just code)

I hope you enjoy the reading.

A Upcoming Pandemic of Domain Anaemia

PeterRitchie — Thu, 29 Jan 2009 06:00:00 GMT

There's a well-known anti-pattern called the anaemic domain model[1][2]. This anti-pattern basically says domain entities, chronically, have little or no behaviour (remember, object-oriented design is about attributes and behaviour).

It should be obvious that a domain model that isn't truly object oriented is a domain model with a problem. But, let's look at other reasons why the Anaemic Domain Model is an anti-pattern. Your Domain is the nexus, the essence, of your system.

An anaemic domain model is basically a reporting system. Each "Entity" becomes, essentially, a query. This is fine, reporting systems are necessary and prevalent. But, to shoe-horn a domain model on top of this leads away from good reporting patterns that could add value and increases complexity, needlessly. The designers spend most of their time trying to force entities on the system, without recognizing the basic reporting nature of the system. This usually leads to "reports" that have to pull in multiple domain "entities" to generate the report--rehydringing data into an entity (usually through some sort of ORM) with no value added. i.e. an ORM that will manage the child-parent relationship (and either pre-load or lazy-load aggregates) doesn't provide much value here.

The worst case scenario with an anaemic domain model is that there really is behaviour there; but it's not handled in the domain entities; it's handled in a different layer. This is a problem because this circumvents the whole point of a domain model and layering.

One indication of anaemia is that most of the domain classes simply contain attributes. Anyone familiar with patterns should recognize this as a Data Transfer Object, not a Domain Entity. There's nothing wrong with DTOs, they're very important in almost all systems with any sort of complexity; but they're not Domain Entities. Let's be truthful, there are systems with little or no behaviour in the domain; and that's not a bad thing. Systems like this likely don't need a Domain Model and may not need techniques like Domain Driven Design. The quicker people recognize that, the quicker they can be using a more appropriate architecture and design. In some extreme cases the anaemic-domain-entity-DTOs service other DTOs

Now, where am I going with this? Well, there's been a series of guidance out of Microsoft Patterns and Practice about some application "patterns".

First, let me describe what a pattern is. A pattern is a way of "documenting a solution to a design problem" [3]. First, for it to be a pattern, it needs to detail the problem and it's context, then provide a solution. The latest "patterns" from P&P do not detail the problem or a context. They're simply architectural descriptions.

Now the association between the Anaemic Domain Model and the latest P&P guidance. In 3 of the 5 recently publish "patterns" the following is detail is included: "A Domain Entity pattern is used to define business entities that contain data only." This is the very definition of an Anaemic Domain Model. Plus, in the RIA pattern the following, contradictory, detail is included: "Domain entities are responsible for implementing business rules. Entities from the domain model represent business objects that contain data and implement behavior [sic]. In other words, the business objects are responsible for implementing business operations and interacting with other business objects."

This is disconcerting because historically sample code and guidance from Microsoft is simply reused without thought. This leads to poorly designed and architected applications, and the .NET community as a whole is seen as one that produces poor-quality code and design. Without context about the problems these patterns try to solve, they will be misused—likely forced upon contexts and situations where they don’t fit, simply because “they’re from Microsoft”.

[1] MF Bliki- AnemicDomainModel

[2] Anemic Domain Model - Wikipedia, the free encyclopedia

[3] Design pattern (computer science) - Wikipedia, the free encyclopedia

Technorati Tags: Microsoft Patterns and Practicies,Anti-patterns,Anaemic,Anemic,Domain Model,Microsoft

del.icio.us Tags: Microsoft Patterns and Practicies,Anti-patterns,Anaemic,Anemic,Domain Model

Using Interception with Dependency Injection: EL 4.1 and Unity Spring 1.2 create new avenues

Manoj — Fri, 16 Jan 2009 06:00:00 GMT

It is customary to conceive any large application to be composed of several logical layers. It is also a practice to reduce the coupling between the layers. Typically, one would create an interface for each class of each layer and they would be coupled to the downstream layer classes only though interfaces.

You would also typically want to unit test each class in each layer. By definition, each of unit test would test a method of only one class and not the downstream classes it depends on. To achieve this , one would need to mock out the instances of the classes which the class being unit-tested depends on. To bring all of this to play effectively, you need to implement the Dependency Injection pattern in your application. Dependency injection is provided by Unity application block.

The application we talked about earlier has in addition to a lot of business logic, several pieces of cross cutting logic - logic applicable to all classes - like logging, tracing, authorization, validation etc. The code for these concerns are usually generic. It would be an awful amount of work to implement these generic pieces of code in every class (or a group of classes) of your application. What you really need is some way to stitch these concerns into the application without disturbing the application code too much. This style of programming is called Aspect Oriented programming (sort of). This capability is provided by the Policy Injection Application block.

Now, to me, both aspects discussed above are very important to any application. In other words, any application would need both dependency injection along with some type of aspect orientation (or policy injection or interception). The question really is - how do you really bring them together?

I am assuming that you are familiar with these blocks I just mentioned. To have rubber meet the road, we really need to marry IContainer.Resolve<T> and PolicyInjection.Create<T>(). This was not possible as of EL 4.0 and left me hoping. It is possible now - with EL 4.1 (along Unity 1.2). The interception capability comes as a extension which can be associated with the Unity container. Therefore, you can have policies associated with the container which govern which call handlers are added. The real beauty is this - the application classes really work with the IContainer interface. In an actual environment, you need to associate the container which has the correct dependencies and interception policies. The unit testing environment would basically replace the container with one where the Interception extension is not applied, and therefore, the unit tests would not really execute any cross-cutting logic (of course, you can choose otherwise). Neat!

I have just started to dabble with this ability, and a lot of questions still need to be answered. One that comes immediately from the top of my mind is performance. When a class is set to be intercepted, what would be the performance overhead, and what would be the overhead based on the type of interceptor (TransparentProxyInterceptor, VirtualMethodInterceptor or InterfaceInterceptor)? Obviously, there are no definitive answers and it all depends on the policies and handlers you add to your application. I have a reason to believe that the cost of interception is not usually so high, that is deemed only for academic purposes. One would need to perform relevant tests to ratify the same in her application on the representative environment. The second question, but seemingly more subtle, is instancing. The new interception features either work on the RealProxy based interception, or dynamic code generation. Obviously, it would be more efficient to reuse these instances at runtime instead of generating them for every call. Now, if you have singleton instancing, the real question is about thread safety. How does a dynamically generated instance serve multiple request threads at a time - as it happens in web applications in production?

Having opened these questions, I would write up a follow-up post which hopefully addresses these. In the meantime, I will dabble with more scenarios using these new capabilities, and keep you posted.

Pontificating Virtual Parameterized Constructors in C#

PeterRitchie — Tue, 18 Nov 2008 06:00:00 GMT

Tom Hollander recently posted about a change he required to the Enterprise Library for date/time validation. He had to create a new class (rather than modify the Enterprise Library) that derived from another, defective class. One of his complaints was that in order to effectively implement the base class he had to also write matching constructors that simply called the base class. His suggestion was effectively to add the concept of virtual parameterized constructors to C#. I detail “parameterized constructors” because C# already effectively has virtual default constructors. In the following example the base constructor (Form()) is automatically called by the derivative:

    public class MyForm : Form
    {
        public MyForm()
        {
        }
    }

Virtual parameterized constructors are not new, and from a mere language standpoint this seems reasonable. Pragmatically though, I believe, this is another story. It seems logical to be able to simply inherit the parameterized constructors of the base class; but, there are so many times that this isn't the case or some generally accepted principles that would be contravened by a language addition like this.

Let's first look at the open/closed principle (OCP). The OCP suggests classes should be open for extension but closed for modification. Robert Martin suggests [1] properly designed class hierarchies that obey OCP implement an abstraction; i.e. derive from an abstract class or implement an interface. For example:

public interface IShape
{
    void Draw(Graphics graphics);
}
 
public class Rectangle : IShape
{
    //...
    public void Draw(Graphics graphics)
    {
        ///...
    }
}

Second, let's look at the "prefer composition over inheritance" principle. The effect of a language change like this on a design that prefers composition should be fairly obvious. Here's an example of this principle:

public interface IPolygon {
    void Draw(Graphics graphics);
}
public sealed class Polygon {
    private readonly Point[] points;
    public Polygon(Point[] points) {
        this.points = points;
    }
    public void Draw(Graphics graphics) {
        for(int i = 1; i < points.Length; i++) {
            graphics.DrawLine(Pens.Black, points[i-1], points);
        }
    }
}
 
public class Rectangle : IPolygon {
    private readonly Polygon polygon;
    public Rectangle(Point location, Size size) {
        Point[] points = new Point[5];
        points[4] = points[0] = location;
        points[1] = new Point(location.X + size.Width, location.Y);
        points[2] = new Point(location.X + size.Width, location.Y + size.Height);
        points[3] = new Point(location.X, location.Y + size.Height);
        polygon = new Polygon(points);
    }
    public void Draw(Graphics graphics) {
        polygon.Draw(graphics);
    }
}

Obviously there is no way to use virtual parameterized constructors here.

Clearly, designs that take into account OCP and prefer-composition-over-inheritance would not benefit from a "virtual parameterized constructor" language addition.

Finally, let's look at why a class might have many constructors causing such friction for derivatives. There's many reasons why a class might have many constructors. I believe all are indications of a poorly designed class. My first thought would be that many constructors is a result of a large class and that the large-class-code-smell should be an indication for redesign. A large class could be in an indication of a motherclass; but in either case this is likely a single responsibility principle (SRP) violation and the class is doing much more than it should and be redesigned. If the class isn't large but has many constructors, this was likely done not in response to how the class should/would be used but to cover every possible way of constructing the type. This would then be a YAGNI violation and the number of constructors should simply be pared down.

But, what about when you have to deal with poorly design hierarchies and don't have the ability to modify them? A valid point; but, simply for the lack of friction of writing pass-through constructors I don't think adding to the language to support poorly designed classes is a good for the language or its developers.

While an addition like virtual parameterized constructors seems benign, its limited actual usefulness makes the effort not worth the reward. Plus, it introduces greater abilities to create poorly designed types.

[1] http://www.objectmentor.com/resources/articles/ocp.pdf

First Code Parts of Prism 2.0

NunoGodinho — Fri, 26 Sep 2008 05:00:00 GMT

As I previously posted, Prism 2.0 is shaping up and some of the new Code Parts are already available on CodePlex. Of course this is only a small part but it brings good news like:

Multi-targeting quick starts, that explains the structure that a Prism 2.0 project will have in order to be Multi-target for WPF and Silverlight, and in this case is a real state solution.
Multi-targeting Visual Studio Templates, in order to be possible to create the Prism 2.0 projects.
Project Linker Tool, that provides a guidance on how to structure an application in a way that is possible to link it to other applications in order to make it Multi-targeted.

Read more about it in the Readme file that defines this first drop, and also David Hill’s blog post about this subject.

Composite Application Guidance for WPF (Prism) now goes to Silverlight 2.0

NunoGodinho — Wed, 06 Aug 2008 05:00:00 GMT

As I said in a previous post Composite Application Guidance for WPF formerly known as "Prism" was made available and this was a great news because now the development of WPF solutions is easier and as a Guidance that will lead us all the way, helping us make the right choices whenever problems emerge. This is great but being Silverlight a subset of WPF, so wouldn't be great to have the same kind of guidance for Silverlight 2.0?

This is precisely what the team thought and then they started working on it and now we have some "spike's" (A ’spike’ is a small and quickly developed sample application in order to mitigate some risks) being released that will do exactly this, as is announced by Ezequiel Jadib on his blog. It's worth to check and I think it will be very interesting in the near future.

Composite Application Guidance for WPF

NunoGodinho — Tue, 08 Jul 2008 05:00:00 GMT

WPF is a very interesting technology since it provides the possibility to have a better User Experience on our Windows Applications, and by doing so it attracted many designers, enthusiasts as well as Developers, Architects and IT Managers, but what happens with new technologies is that sometimes they are misused by developers and became a problem. And so in order to help developers and architects attend to this type of problems the Patterns and Practices Team has been working on a project named "Composite Application Guidance for WPF", that will make the necessary "mind" adjustments and bring flexibility to the development of new applications in WPF.

This comes on a road that has been very useful on several other technologies like, Web Client Software Factory for ASP.NET, Composite UI Application Block and Smart Client Software Factory for Smart Clients, and even the Enterprise Library, and by doing this the developer has a kind of guideline making the process of developing solutions a little easier.

So check this out here .