SeeSharp - SeeSharp

Deserting SVN for good: Using Git

HEskandari — Sun, 07 Mar 2010 18:00:00 GMT

I've been having tremendous amount of problems lately using TortoiseSVN. Although server seemed to work fine, my SVN client had lots of problems, so I decided it was time to switch to Git. I was using the free service available at xp-dev but the free service only includes SVN repositories, so I tried the next best thing: GIT-SVN. Let's see how it worked out for me.

Git is not (yet) natively supported on windows. The only way to run it on Windows was to use Cygwin, a linux like environment for Windows, but the new project called msysgit is trying to make a native Windows client. To get started download and install msysgit from google code. I'm using version 1.6.5.1 preview 20091022 at the time of this post, but it is updated regularly.

To connect to SVN repository, open a Git Bash window on your destination folder and enter the following command:

git svn -s clone http://your-svn-address

If your SVN repository has no standard folders such as "trunk", "tag" and "branch" you should remove "-s" parameter. This command would get all the sources, except empty folders in your existing SVN repository because Git does not track folders but file content. It would take some time for git to get all the revisions but when it finishes, you're all set.

From this point on, you can use git commands but before committing changes back into your SVN repository, you should update your working folder by the following commands:

git svn fetch
git svn rebase

This will update your local git working copy by getting all the changes made by other people and then applies your local changes over that.

The last command to send your changeset to the SVN repository is the following:

git svn dcommit

To find out more about git commands, try this cheat sheet that comes handy.

Silverlight Applications with J2EE Backend - Part Two

HEskandari — Sun, 07 Mar 2010 08:00:00 GMT

In previous post, we saw how easy it is to use J2EE as a rich backend. Let's continue with our example and show how to fetch and send some data from our J2EE backend to a Silverlight rich client application. Let's continue our work using a simple Blog domain model.

To create our simple domain model, let's create the domain classes in java and let JPA create the database for us. For .NET developers familiar with NHibernate and NHibernate Mapping Attributes project, when comparing this to .NET coding style, there should be nothing new here. Here's a piece of code:

package ir.hightech.silverbox.domain;

import javax.persistence.*;
import java.util.List;

@Table(name = "sl_Post")
@Entity
public class Post {

    private int postId;
    private String title;
    private Blog blog;
    private List<Comment> comments;

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "PostId", nullable = false)
    public int getPostId() {
        return postId;
    }

    public void setPostId(int postId) {
        this.postId = postId;
    }

    @ManyToOne
    public Blog getBlog() {
        return blog;
    }

    public void setBlog(Blog blog) {
        this.blog = blog;
    }

    @Column(name = "Title", nullable = false)
    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    @OneToMany(mappedBy = "post")
    public List<Comment> getComments() {
        return comments;
    }

    public void setComments(List<Comment> comments) {
        this.comments = comments;
    }
}

package ir.hightech.silverbox.domain;

import javax.persistence.*;

@Table(name = "sl_Comment")
@Entity
public class Comment {

    private int commentId;
    private Post post;
    private String text;

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "CommentId", nullable = false)
    public int getCommentId() {
        return commentId;
    }

    public void setCommentId(int commentId) {
        this.commentId = commentId;
    }

    @ManyToOne()
    public Post getPost() {
        return post;
    }

    public void setPost(Post post) {
        this.post = post;
    }

    @Column(name = "CommentText", nullable = false)
    public String getText() {
        return text;
    }

    public void setText(String text) {
        this.text = text;
    }
}

Let's create a service to return a list of all available Posts and display them on our Silverlight client. Continuing from previous post, you've already learned how to create services (or SessionBeans as called in EJB context) but when you actually have an entity model and want to expose it through service, you'd better think twice. There are a lot of things that can go wrong if you do so:

Your change in domain model will ripple to your clients because of changes in service contract and will probably break all your clients.
Your domain model might contain sensitive information which is best kept on your service tier.
Other technical stuff such as your entities beiing lazy and having problems with serialization process.

So before continuing, let's create some DTO objects which will be sent across the service boundary. For this sample, a POJO class resembling your existing Post entity would suffice. To map between Entities and DTOs, you can roll your own mapper classes.

package ir.hightech.silverbox.common;

import ir.hightech.silverbox.domain.Post;
import javax.ejb.Remote;
import java.util.List;

@Remote
public interface BlogService {
    List<PostDto> getAllPosts();
}


package ir.hightech.silverbox.services;

import ir.hightech.silverbox.common.BlogService;
import ir.hightech.silverbox.domain.Post;
import javax.ejb.*;
import javax.jws.*;
import javax.persistence.*;
import java.util.*;

@Stateless(name = "BlogService")
@Remote(BlogService.class)
@WebService
public class BlogServiceImpl implements BlogService {

    @PersistenceContext
    protected EntityManager em;

    public List<PostDto> getAllPosts() {
        Query query = em.createQuery("FROM Post");
        List<Post> result = query.setMaxResults(10)
                                 .getResultList();

        return new PostMapper().MapMany(result);
    }
}

Did you notice the EntityManager? It is injected automatically by EJB container and the good thing is you can inject other services, even your other EJB session beans too. EntityManager provides functionalities similar to ISession in N/Hiberante such as CreateQuery, Find, Attach/Detach, Flush, etc.

Now let's create a new Silverlight application and add a new "Service Reference" to your project which points to our new service at:

http://localhost:9090/Silverbox/BlogService?WSDL

Note: Use IP / Port of your JBoss server, port is usually 8080. Mind the small / caps characters.

If you open the proxy sources which is automatically generated, you'll notice our DTO objects are all here in our Silverlight application now! There's a slight modification though: All the classes and properties are named according to java naming conventions so our PostDto class is now named "postDto" on the Silverlight client. This is happened to all the properties of the proxy classes too so if you're binding generated classes directly to your UI keep in mind that Xaml binding are case sensitive. What is good is that INotifyPropertyChange is already implemented. The rest is just regular Silverlight application calling a remote service:

<Grid x:Name="LayoutRoot">
    <ListBox x:Name="RecentPosts">
        <ListBox.ItemTemplate>
            <DataTemplate>
                <StackPanel Orientation="Horizontal">
                    <TextBlock Text="{Binding Path=postDate}" />
                    <TextBlock Text="{Binding Path=title}" />
                </StackPanel>
            </DataTemplate>
        </ListBox.ItemTemplate>
    </ListBox>
</Grid>

and to call the service:

private void MainPage_Loaded(object sender, RoutedEventArgs e)
{
    var service = new BlogServiceImplClient();
    service.GetAllPostsCompleted += (snd, arg) => 
    {
        if(arg.Error == null)
        {
            RecentPosts.ItemsSource = arg.Result;
        }
    };
    service.GetAllPostsAsync();
}

You should have a rich application that is bound to your database using your service layer on J2EE. Pretty easy so far, don't you think?

Next post in this serie will show you how to handle business validation using SoapFaults, how to serialize Java exceptions into Silverlight client and how to actually deploy the whole application. Get the sources of this part from here.

PersianCalendar support for DevExpress

HEskandari — Fri, 26 Feb 2010 08:57:00 GMT

Creating Line of Business applications using DevExpress WPF controls is just a breeze. The actual application is nice looking too! Since there are a couple of skins available and the good thing is the skin also changes the look and feel of standard WPF controls!

I've used my calendar library to develop a fully localizable solution. These controls support Gregorian, Hijri and Persian calendars so multicultural application development would be seamless, but the look and feel of my controls were a lot different than the ones provided by DevExpress. On the other hand, DevExpress only supports Gregorian calendar! So I needed to apply look and feel of DevExpress to my controls. It goes without saying that you can open the controls in Expression Blend and give it a style that mimics DevExpress look and feel, but that is not easy to do.

DevExpress provides a PopupEditBase control that can be used to display any control as a Popup. That seemed to be a good choice and it was easy to create a new control all in xaml markup:

<Window x:Class="DXCustomEditor.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
        xmlns:dxe="http://schemas.devexpress.com/winfx/2008/xaml/editors" 
        xmlns:fx="http://schemas.hightech.ir/wpf/2008/FarsiLibrary"
        Title="DX Editors" Height="350" Width="525"
        xmlns:loc="clr-namespace:DXCustomEditor">
    <Window.Resources>
        <loc:DateConverter x:Key="DateConverter"/>
        <ControlTemplate x:Key="DatePickerTemplate">
            <fx:FXMonthView SelectedDateTime="{Binding Path=(dxe:BaseEdit.OwnerEdit).EditValue, Mode=TwoWay, RelativeSource={RelativeSource Mode=TemplatedParent}, Converter={StaticResource DateConverter}}"/>
        </ControlTemplate>
    </Window.Resources>
    <StackPanel Margin="10">
        <dxe:PopupBaseEdit IsTextEditable="False" PopupContentTemplate="{StaticResource ResourceKey=DatePickerTemplate}" />
    </StackPanel>
</Window>

The outcome is pretty good: seamless calendar support and look and feel.

Silverlight Binding: Lesson Learned

HEskandari — Wed, 17 Feb 2010 10:00:00 GMT

When working on a Silverlight application that recieved data from a WebService I notice that loading of an array of 1500 items takes a lot of time. With this problem, application launch that has 3 separate webservice lookups, took almost 5 minutes to complete.

The problem became more interesting when my colleague actually ran get the same data bound UI in WinForms in 2 seconds, so there were something fishy going on in out Silverlight application. Let's see the original code that loaded the data from the webservice:

public virtual void Load()
{
    var client = new ServiceClient();
    client.GetAllFirstLookupCompleted += (s, e) => Lookup.AddRange(e.Result.MapMany<LookupResult, LookupResultDTO>());
    client.GetAllFirstLookupAsync();
}

public virtual ObservableCollection<LookupResultDTO> Lookup
{
    get; private set;
}

WebService call returned a "LookupResult" but we used LookupResultDTO object bound to UI so the first thing we needed to do was to convert between these types. Then our bound collection was a ObservableCollection. Unlike the same type in WPF, ObservableCollction in Silverlight has no construct that accepts an IList so you have to add individual items one by one! To make things "look" niceer, we've created an AddRange extension method that add items of an IList to an ObservableCollection.

So, why would the above code take this long?

First Mistake

First mistake was to use AutoMapper! Yes, it makes life easier by automagically map two unconvertable types by using reflection and flatting structure. It even works great if your collections are relatively small but avoid using it if you have a large collection (I don't even consider a collection of 1000 items large!).

You can always roll your own mappers and it is easy to create and use. Our mapper looked like this:

public class LookupResultMapper
{
    public LookupResultDTO MapOne(LookupResult result)
    {
        return new LookupResultDTO(result.PrimaryKey, result.Name, result.Number);
    }

    public IList<LookupResultDTO> MapMany(LookupResult[] results)
    {
        var list = new List<LookupResultDTO>();

        foreach (var result in results)
        {
            list.Add(MapOne(result));
        }

        return list;
    }
}

The reason is obvious! Using reflection is a lot slower and when you're doing it for 1000 times, you'll get 1000 times slower! This small change improved the performance more than 50%.

public virtual void Load()
{
    var client = new ServiceClient();
    client.GetAllFirstLookupCompleted += (s, e) => Lookup.AddRange(new LookupResultMapper().MapMany(e.Result));
    client.GetAllFirstLookupAsync();
}

Second Mistake

When a UI element is bound to an observable collection, every addition and removal of an Item probably lead to some calculation in the element for things such as draing and layout calculation. Second problem was to add the collection one by one to the observable collection.

Unfortunately, as mentioned, ObservableCollection unlike WPF version has no construct that accepts an IList. You have some options though:

Make your UI element Invisible (Visibility=Collapsed or Hidden) then add the items to the bound collection. This will prevent exhaustive calculation.
Change the collection type from ObservableCollection to IList, if possible.

Depending on your scenarios, one of the above mentioned solutions may work for you. In our case, we didn't need to add / remove items from the collection at a later time so switching to IList did the trick.

After refactoring, application that took almost 5 minutes to launch now runs in seconds!

Silverlight Applications with J2EE Backend - Part One

HEskandari — Sat, 13 Feb 2010 16:21:09 GMT

If you have not heard, Silverlight is the latest rich client technology from Microsoft. The good thing about it is that it works almost on all browsers and operating systems and you can host your application on non-microsoft stack too, but there are things such as database connectivity that you can't benefit from when creating Silverlight applications. The only way to create data-driven applications would be to use a service backend. Here I'll show you how to create a J2EE backend for your Silverlight application and host it on a JBoss application server.

To create the backend for the Silverlight application, I'll show you how you can use J2EE technology which provides rich infrastructure for your backend. I'll be using JBoss 4.2.3 GA application server to run this sample, and IntelliJ IDEA 9.0 Enterprise to develop the backend. IntelliJ IDEA Enterprise is not a free IDE (there's a free Community version), but using it is natural for .NET developers having experience with Resharper addin tool for Visual Studio .NET. Of course, both tools are from the same company, but if you use Resharper with IntelliJ shortcuts most of them work in IntelliJ IDEA too. You can get a trial version from here for this experiment if you're an experienced java developer, you can still use your favorite IDE.

This post is intented for .NET developers with (almost) no experience with Java language. If you're familiar with NHiberanate, theorethically you should be able to use JPA in no time because of a lot API similarities: JPA provides APIs that are very familiar with (N)Hiberante.

Project Structure
For our backend we'll use a standard J2EE project, with support for JPA, JAXWS WebServices and other J2EE services. Fire up your IntellliJ IDEA and create a new project. In the project wizard, select "Java Module" and set path for your project sources. From the technologies page in the wizard, select "JavaEE Persistence", "Enterprise JavaBeans", "JavaEE Application" and "WebServices". The wizard will download the JAR filles and libraries that are necessary from JetBrain's website and set the project structure for you. Before we're done with the project structure, we need to do some modifications.

Thanks to EJB 3.0 and its annotation-based EJBs no xml configuration would be necessary, so open "ejb-jar.xml" file and remove its content (enterprise-beans tag and its content). This file is in META-INF folder in the root of the project. Then open the "persistence.xml" from META-INF folder under the "src" folder and setup the persistence API.

Note: If you have hard time finding any class or file use the same shortcut as in Resharper (CTRL+SHIFT+N for files and CTRL+N for classes and interfaces).

This file is almost like hibernate configuration file so most of the content should be self explanatory:

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="2.0">
    <persistence-unit name="NewPersistenceUnit">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <jta-data-source>java:/silverbox-ds</jta-data-source>
        <properties>
            <property name="hibernate.connection.url" value="jdbc:sqlserver://127.0.0.1;databaseName=silverboxdb"/>
            <property name="hibernate.connection.driver_class" value="com.microsoft.sqlserver.jdbc.SQLServerDriver"/>
            <property name="hibernate.connection.username" value="sa"/>
            <property name="hibernate.connection.password" value="12345"/>
            <property name="hibernate.archive.autodetection" value="class"/>
            <property name="hibernate.show_sql" value="true"/>
            <property name="hibernate.format_sql" value="true"/>
            <property name="hbm2ddl.auto" value="update"/>
        </properties>
    </persistence-unit>
</persistence>

Other than database configuration, notice the "jta-data-source" tag which points to a specified datasource name. We'll learn about this in a bit.

IntelliJ Enterprise integrates with most of the application servers, including JBoss. First make sure you have a working version of JBoss application server which you can download from here. Open the Settings menu (CTRL+ALT+S) and from the Application Servers add a new JBoss Server and select the folder where you unzipped the JBoss package. Then in IntelliJ open the "Edit Configurations" submenu from "Run" menu and add a local JBoss Server. The already added JBoss server will be added. Select the default "Server Instance". Notice the warning message in the dialog that says "Warning: No artifacts marked for deployment".

Note: Your applications may contain libraries, compiled binaries, services, etc. all will be packaged in a deployable unit. The standard deployment unit in Java is JAR (java archive) but other packages exists, namingly WAR (web archive) and SAR (service archive). All the mentioned packages can be packed and deployed in a single deployment unit named EAR (enterprise archive) file.

To specify what should be contained in the deployable package, we need to specify the deployment artifacts. To do this, go to "Project Structure" dialog (CTRL+ALT+SHIFT+S) and select the "Artifact" from the side list. Add a new artifact by pressing "+" button. Enter a name for your artifact and select the "JavaEE Application: Exploded" as the type. From the "Output Layout" add the "Module Output" and a "JPA Descriptors". From the bottom of the page, click "Create Manifest" button to create an empty manifest in your "src\META-INF" folder.

Open up the "Project Structure" dialog again and check the "Build Artifacts..." check mark and from the dialog select the artifact name you've just created.

The project structure is almost ready. Now let's add some code.

Create Enterprise Beans
Under the "src" folder create two packages (a.k.a namespaces). I've named the packages as "ir.hightech.silverbox.common" and "ir.hightech.silverbox.services". I will separate the service interfaces and implementation in separate folders. To create a basic loopback service create the following interface in the "common" package:

package ir.hightech.silverbox.common;

import javax.ejb.Remote;

@Remote
public interface LoopbackService {
    void echo();
}

...and create the implementation in the "services" folder:

package ir.hightech.silverbox.services;

import ir.hightech.silverbox.common.LoopbackService;
import javax.ejb.Remote;
import javax.ejb.Stateless;

@Stateless(name = "LoopbackService")
@Remote(LoopbackService.class)
public class LoopbackServiceImpl implements LoopbackService{
    public void echo() {
        System.out.println("Hello, world!");
    }
}

Note: Each EJB can be used locally or remotely so different annotations are required based on usage context. Since we need to only expose the EJBs as a service, we've only specified it to be a "Remote" service / interface.

Final step would be to expose the EJB as a Webservice. That is as easy as adding an annotation to our service implementation:

@Stateless(name = "LoopbackService")
@Remote(LoopbackService.class)
@WebService
public class LoopbackServiceImpl implements LoopbackService{
   ...
}

Data Sources
Before we deploy and run the application, we need to setup the datasource specified as "jta-data-source" in our "persistence.xml" file. JBoss when ran searches the deploy folder for the specified datasource. Datasource file names are ended with "ds" suffix by convention. The datasource file contains connection information that will be used in our application. Here the "jndi-name" is important and it should be the same thing as what we've specified in persistence.xml file. To use MS-SQL 2005 database create the following file and copy the file in the "deploy" folder of the JBoss. You can create an ANT script and automatically copy this file into the destination folder, if you prefer.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<datasources>
    <local-tx-datasource>
        <jndi-name>silverbox-ds</jndi-name>
        <connection-url>jdbc:sqlserver://127.0.0.1;databaseName=silverboxdb</connection-url>
        <driver-class>com.microsoft.sqlserver.jdbc.SQLServerDriver</driver-class>
        <user-name>sa</user-name>
        <password>12345</password>
        <metadata>
            <type-mapping>MS SQLSERVER2000</type-mapping>
        </metadata>
    </local-tx-datasource>
</datasources>

Deployment
We're almost there now. From the main toolbar, click the "Run" button to fire up the JBoss server. Notice the logs that appear in Output window of the IntelliJ IDEA. If you see that artifact is deployed successfully, you're good. Fire up your browser and enter the services url to see the automatically generated WSDL. The deployed URL would be http://localhost:8080/Silverbox/LoopbackService?WSDL but if you've named your artifact and service something different it is in the format of http://jbossmachine:port/artifactname/Servicename (you can also see the registered Endpoint in the output window).

Next we'll see how to extend the service and create a Silverlight client that accesses our backend. Get the source files for this part from here.

Must Read Books For Programmers

HEskandari — Thu, 21 Jan 2010 08:00:00 GMT

It's been a while that I wanted to prepare a list of books that, in my opinion, every programmer should read. These are the most influential books I've read so far in my career. It is not supposed to be a complete list of any kind and this is just my idea of a must read. Books mentioned here may or may not be specific to a programming language, so check it before you buy the book.

With the fact (or is it a fiction?) that programmers don't like to read books in mind, I limited the list to only ten books, but there are certainly other great books out there that either I'm not aware of or may be have not read yet. I was already a programmer when I read most of these books, but these really helped me open my mind towards how professionals are doing it and why.

Enough said, here's the list:

10- Design Patterns: Elements of Reusable Object-Oriented Software by Gang of Four
9- Clean Code A Handbook of Agile Software Craftsmanship by Robert C. Martin
8- Agile Project Management with Scrum by Ken Schwaber
7- Applying Domain-Driven Design and Patterns by Jimmy Nilsson
6- Working Effectively with Legacy Code by Michael Feathers
5- Patterns of Enterprise Application Architecture by Martin Fowler
4- Refactoring: Improving the Design of Existing Code by Martin Fowler
3- Test Driven Development By Example by Kent Beck
2- Agile Principles Patterns and Practices by Robert C. Martin
1- Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans

Thoughts?

Java and .NET Interoperability

HEskandari — Mon, 18 Jan 2010 00:00:00 GMT

We've been doing a lot of Java / .NET interop for last couple of years in our enterprise applications. On one hand, our customers used their existing expertise and infrastructure that worked better with Java based technologies like their existing Unix based servers, Sybase database (on Unix) and the knowledge of their DBA team, and we using our existing Java developers and expertise. But what Java based technology provides that we don't have on .NET world? Is it important at all?

With rise of Silverlight presentation framework working the interop becomes more important. You can now create a sophisticated user interface and make it work with your existing EJBs on your JBoss backend and you have best of both worlds. As a .NET developer you might not be familiar what this provides, so here's a few things you'll get right out of the box:

Standard JPA (Java Persistance API)
When you create applications on top of EJB 3.0 using any EJB compliant application server, one thing you get is a standard, pluggable persistence API. The idea behind JPA was to provide a standard set of interfaces to application developers and let the application server provide different implementations of these interfaces using various persistence frameworks. Great idea, right? This means you don't need to learn how to use another persistence framework, because now they all support an standard interface.

JBoss actually uses Hiberante under the hood to implement this API but other application servers may have different engines. If you're familiar with NHibernate, you'll feel right at home!

JAX-WS WebServices
Should you need to expose your business logic through WebServices, all you need to do is to decorate your existing services with an Annotation to signify the application service that the class provides a WebService endpoint. An Annotation is actually a Java term for almost the same thing we call an Attribute in .NET world.

Infrastructural Services
There are a lot of cross cutting concerns your application server provides. Things such as standard logging framework, inversion of control container, queues, scheduling, Message Driven Bean (which is a very simple ESB) , hot deployment of applications, etc.

Price Tag
Yes, the best part of it is that all of this comes as free (as in free food). You don't have to pay for licenses for your application server, you don't have to pay for IDEs because there are a lot of great IDEs available, you don't have to buy license for your Linux based Server and there's a large community out there that can help you freely, if you're stuck. Of course there are paid services too, mostly for services such as support, but you hardly need it. If you're pairing Silverlight frontend with Java backend, you can use Eclipse to handle both in one place!

This is just a scratch on the surface. I'll shed more light on the subject on upcoming posts.

WPF Application with Caliburn - Part Two

HEskandari — Fri, 15 Jan 2010 00:00:00 GMT

In this part of the tutorial, we'll enhance our shell view to display other presenters and add Save and Print support for presenters supporting it. You can use generalize this example and learn how to implement generic features in your shell.

Caliburn has several existing classes that can be used as a base class for our presenters. Let's explain some of them and see where do they fit:

Presenter
This class implements IPresenter interface and provides life time methods such as Initialize, Shutdown, Active and Deactive. You can use this class for other views that are going to be displayed in the Shell View.

Presenter Manager
Using a presenter manager, as the name implies, you can host and display a single instance of a Presenter. It only allows displaying of one Presenter only so you have only one view displayed to the user when using it.

MultiPresenterManager
Same as PresenterManager but can host multiple Presenters at the same time, but only one of them is Active at a time.

When we display a Presenter, the PresenterManager will call the lifetime methods on the Presenter instance. The following diagram shows this flow:

For now, it is obvious that we need to change the base class of our ShellViewModel to PresenterManager (too keep it simple for the time being), but how should we change the xaml code to host the views (other Presenters)? Your first guess would be to bind CurrentPresenter property of the PresenterManager to a ContentControl in the Shell.xaml, but you don't need to do that as Caliburn will do the plumbing for us, just add a ContentControl to the Shell view where you want the views to be displayed and name it as "CurrentPresenter".

To make Caliburn bind Views to the content control, you need to enable additional Conventions that are not enabled by default. Placing the following snippet in Caliburn configuration will do the trick:

var binder = (DefaultBinder)Container.GetInstance<IBinder>();
binder.EnableBindingConventions();

The bare bone of the shell view that displays a single presenter is this:

<Window x:Class="PayRoll.Views.ShellView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Width="640" Height="400">
    <DockPanel LastChildFill="True">

        <ScrollViewer>
            <ContentControl x:Name="CurrentPresenter" />
        </ScrollViewer>

    </DockPanel>
</Window>

Adding Custom Controls
Now to handle user interaction with the shell and the open presenter, we need some kind of a Toolbar / Menu control. WPF comes with a very basic menu and toolbar control, but to show how to use custom controls and see how Caliburn facilitates this, let's use DevExpress BarManager control in this example.

DevExpress, among other nice things, provides presentation layer controls for WPF such as Editors, Bars (MenuBar, ToolBar and soon Ribbon), Grid and Printing. One other thing they've also done is that they also have skinned native WPF controls so if used together with DevExpress controls, you'll have a seemless look and feel.

To add the BarManager control to our ShellView, you need to download DevExpress WPF controls (trial version here) and install it. The add the necessary reference to devexpress WPF assemblies and import the xml namespaces. Here's the snippet that creates the BarButtonItems which is equivalent of a ToolbarItem. (Get the accompanied zip for complete source code):

<dxb:BarManager.Items>
	<!--General Actions-->
	<dxb:BarButtonItem Name="bSave"  CategoryName="File" Content="Save" Glyph="/Images/Save.png"  KeyGesture="Ctrl+S" />
	<dxb:BarButtonItem Name="bPrint" CategoryName="File" Content="Print" Glyph="/Images/Print.png" KeyGesture="Ctrl+P" />
	<dxb:BarButtonItem Name="bExit"  CategoryName="File" Content="Exit" Glyph="/Images/Exit.png" KeyGesture="Ctrl+X" />
	
	<!--Status Bar-->
	<dxb:BarStaticItem Name="bStatus" CategoryName="Status" MinWidth="300" Content="Read" AutoSizeMode="Fill"/>
</dxb:BarManager.Items>

Same as Button object, BarButtonItems provide a Command property which you can bind to an ICommand instance on your ViewModel, but this is rather limited, don't you think? What if you want to bind another event (other then Click) to your ViewModel?

Caliburn provides Actions and Messages with which you can bind a regular Event on your View and Controls to a method on your ViewModel, without using ICommand. You can even run the event handler (on your VM) asynchronously! There are a few ways to do this but the best way, in my opinion, is to this format:

cal:Message.Attach="[Event EventNameOnControl] = [Action ActionNameOnViewModel()]"

Note that you can actually bind two actions to one event, just like you can have two methods listening to a regular event. Let's change the snippet above and add the messaging support:

<dxb:BarButtonItem Name="bSave" cal:Message.Attach="[Event ItemClick] = [Action SavePresenter()]"/>
	<dxb:BarButtonItem Name="bPrint" cal:Message.Attach="[Event ItemClick] = [Action PrintPresenter()]"/>
	<dxb:BarButtonItem Name="bExit" cal:Message.Attach="[Event ItemClick] = [Action Exit()]" />

Note: Unlike a regular Button, BarButtonItem has no "Click" event and provides an "ItemClick" event instead. Clearly, we need the specified methods on our ViewModel, so let's add them too:

public class ShellViewModel : PresenterManager, IShellViewModel
{
    public virtual void SavePresenter()
    {
    }

    public virtual void PrintPresenter()
    {
    }

    public virtual void Exit()
    {
    }
}

At this point, you can run the shell and click the tool bar items, which will call the specified method on the view model. Now the question is, what if a presenter is not in a suitable state to be saved (dirty checking, already saved, etc.). What if a presenter does not even support printing? How can we disable the BarButtonItem responsible for an action, if the presenter does not support it?

With Conventions already enabled, you can have additional "Can*" methods acting as a Filter for your actions. These filters will be checked on runtime for returning false value indicating the action can not be performed, or true value for allowed actions. Caliburn will try to disable the piece of UI through an "IAvailabilityEffect" interface. Let's see this in more dept.

Working with Actions
As mentioned, Caliburn checks for availability of an action automagically if it finds a pairing "Can*" filter method on the presenter. So let's add those and see how it works:

public virtual bool CanExit()
{
    return base.CanShutdown();
}

public virtual bool CanPrintPresenter()
{
    var presenter = CurrentPresenter as IPrintablePresenter;
    return presenter != null &&
           presenter.CanPrint;
}

public virtual bool CanSavePresenter()
{
    var presenter = CurrentPresenter as ISaveablePresenter;
    return presenter != null &&
           presenter.CanSave;
}

When you run the application and set a break point on CanSave and Save methods, you'll notice two things:

A. While CanPrint method returns False value, UI element (BarButtonItem) is not disabled!

B. By clicking the BarButtonItem, the Save method will not be called.

So there seems to be a problem...Why isn't BarButtonItem disabled? Wasn't Caliburn supposed to do that for us? Well...The default "Disable" effect, only works for UIElements, but BarButtonItem is actually a FrameworkContentElement. Those are two different beasts and Caliburn can not handle our UI control. The solution is easy though. You can create your own IAvailabilityEffect that works with FrameworkContentElements.

public class DisableMenuEffect : IAvailabilityEffect
{
    public void ApplyTo(DependencyObject target, bool isAvailable)
    {
        var element = target as FrameworkContentElement;
        if(element == null)
            return;

        element.IsEnabled = isAvailable;
    }
}

...and set it along with the action on the View:

<dxb:BarButtonItem cal:Message.Attach="[Event ItemClick] = [Action SavePresenter()]" cal:Message.AvailabilityEffect="DisableMenuEffect" />
    <dxb:BarButtonItem cal:Message.Attach="[Event ItemClick] = [Action PrintPresenter()]" cal:Message.AvailabilityEffect="DisableMenuEffect" />
    <dxb:BarButtonItem cal:Message.Attach="[Event ItemClick] = [Action Exit()]" cal:Message.AvailabilityEffect="DisableMenuEffect" />

There's one last trick to make this work. Caliburn has no way to convert the specified string to an IAvailabilityEffect instance! The existing ValueCovertor, asks our Container for any object named "DisableMenuEffect". The final piece of code would be to register all instances of IAvailabilityEffects you might want to use on the container:

_container.Register(Component.For<DisableMenuEffect>()
                             .Named("DisableMenuEffect")
                             .LifeStyle.Singleton);

When running the application, and there's no open view, the toolbar items are disabled.

To show how it works, let's add a new View and ViewModel to our application, and also add a button to the shell that allows us to open this view. As mentioned before, to do this, you need to create a UserControl for you View and a class deriving from Presenter base class for your ViewModel.

public class PersonViewModel : Presenter
{
    private Person _person;
    private ObservableCollection<Person> _personnelList;
    private ObservableCollection<Job> _jobs;
    private readonly IPersonDataService _service;

    public PersonViewModel(IPersonDataService service)
    {
        _service = service;
    }

    public override void Initialize()
    {
        _jobs = new ObservableCollection<Job>(_service.GetJobs());
        _personnelList = new ObservableCollection<Person>(_service.GetPersonnel());
    }

    public Person CurrentPerson
    {
        get { return _person; }
        set
        {
            _person = value;
            base.NotifyOfPropertyChange("CurrentPerson");
        }
    }

    public ObservableCollection<Person> Personnel
    {
        get { return _personnelList; }
    }

    public ObservableCollection<Job> Jobs
    {
        get { return _jobs; }
    }
}

Now create a UserControl for PersonView using DevExpress editors looking like this:

To support saving, let's add ISaveablePresenter interface to our ViewModel and check if DateOfBirth property of the current person is valid before saving:

public bool CanSave
{
    get 
    {
        return CurrentPerson != null &&
               CurrentPerson.DateOfBirth.Year > 1900;
    }
}

public void Save()
{
    MessageBox.Show("Saved");
}

You can observe that CanSave property will never get executed! The reason is that when application starts, Caliburn checks if any of the Action methods are available by checking their respective Filters (here CanSavePresenter and CanPrintPresenter), but it never checks them again. In other words, by default action filters (Can* methods) are only called once. How can we change this behavior?

There's an attribute called "AutoCheckAvailability" that you can place on your action methods. This will tell WPF Command Manager to look out for availability of the bound action. Doing this will call the action filters periodically, so make sure if you really need it before actually using it. So apply this to our ViewModel, let's get back to our ShellViewModel class and place the attribute on our actions:

[AutoCheckAvailability]
public virtual void SavePresenter()
{
    var presenter = (ISaveablePresenter)CurrentPresenter;
    presenter.Save();
}

[AutoCheckAvailability]
public virtual void PrintPresenter()
{
    var presenter = (IPrintablePresenter)CurrentPresenter;
    presenter.Print();
}

Note: You need to place this on your actions, not on filters.

...et voila!

Our shell now can host other views and has generic actions that is automagically enabled / disabled for views supporting it.

In the next post, I'll show you how to change our existing shell to display a Tabbed interface and display multiple views at the same time. The attached zip file contains the complete source code.

WPF Application with Caliburn - Part One

HEskandari — Wed, 30 Dec 2009 00:00:00 GMT

Back in May 2008, I did two posts on how to implement a composite application using Caliburn framework. By that time, Caliburn was still in pre-alpha stage. With lots of the changes along the way to reach Release Candidate, those content are not valid anymore, so I thought a new post to show how you can use Caliburn to build a WPF application is in order.

In fact, a while ago I started porting my old .NET 1.1 pay roll application to WPF and .NET 3.5 so I naturally chose to use Caliburn and it did facilitate things a lot, but to keep things simple, I'm not going to discuss my own application here. I'll show how you how can create your own application using Caliburn framework and how it will help you out.

Framework Setup

First thing you need to do, is to setup a new WPF application. Let's call it PayRoll application. After doing so, add reference to Caliburn and Castle assemblies. Caliburn honors the Dependency-Injection principle by depending only on abstractions. The idea is to allow you to easily plug in your own implementation of that abstraction and customize how Caliburn components work. To do so, Caliburn uses an IoC Container to lookup the services it requires.

If you're new to Dependency Injection stuff, don't worry, there is a built-in SimpleContainer which will do the job for you but I'll be using Castle container (Windsor) here. If you're using other IoC containers such as AutoFac, Ninject, StructureMap, Spring or even MEF (not technically an IoC container), Caliburn comes with existing adapters for those too, so no worries. To lookup instances of the services it needs, Caliburn uses the Common ServiceLocator and Service Locator design pattern. This allows looking up for services from various IoC containers, without actually depending on those containers.

Now to initialize Caliburn framework at startup there are various ways, but the easiest would be to create a CaliburnApplication. We already have an application object (App.xaml and App.xaml.cs) so we only need to change them to derive from CaliburnApplication class. To do so, open the App.xaml file first, and include the Caliburn namespace and change the type to Caliburn application. Also, we don't want to specify any StartupUri, so get rid of that too. The result would be this:

<cal:CaliburnApplication x:Class="PayRoll.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:cal="http://www.caliburnproject.org">
    <Application.Resources>
         
    </Application.Resources>
</cal:CaliburnApplication>

With this, the project won't compile! Because we've specified different base classes in our Xaml and Code Behind. Since the base class in code behind is inferred, open the code behind and remove the base class. The code would look like this:

namespace PayRoll
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App
    {
    }
}

So far so good. Now, If you look at the Caliburn Application class, there are interesting things that we can do. The obvious one is a method called CreateContainer. The default implementation, as said before, will create a SimpleContainer but we're going to use our own container, so let's do so:

    protected override IServiceLocator CreateContainer()
    {
        _container = new WindsorContainer();
        return new WindsorAdapter(_container);
    }

Next step would be specifying a RootViewModel (also called ShellViewModel) that will act as ViewModel for our MainWindow. Notice that we have nothing to do with the actual View (UI) that will be displayed, we just specify the ViewModel for it:

    protected override object CreateRootModel()
    {
        return _container.Resolve<IShellViewModel>();
    }

At this point, we need to create a ViewModel and a View for our Shell and register the VM in the container. Create two folders in your solution one named Views and the other ViewModels. Create an interface in ViewModels folder named IShellViewModel and create a class implementing this yet empty interface, named ShellViewModel. So now we need to register these (along with other services, view models, etc.) in the container:

    public App()
    {
        RegisterComponents();
    }

    private void RegisterComponents()
    {
        _container.Register(Component.For<IShellViewModel>()
                                     .ImplementedBy<ShellViewModel>()
                                     .LifeStyle.Singleton);
    }

Notice that lifestyle of ShellViewModel is set to singleton. This is logical because there's always one instance of the ShellView running. We'll see how this allow us interact from other ViewModels with Shell VM.

Marrying the View and ViewModel

Now, let's run the application and see what happens. When we run the application, Caliburn throws an exception complaining that a View can not be created for the ShellViewModel. Since we didn't specify any information about our Views, you might say: How is Caliburn supposed to create a View for my ViewModel anyway? Well, Caliburn tries many things before giving up and throwing an exception:

First, if your ViewModel implements the IMetadataContainer interface, the GetMetadata method is called on your VM, asking for a view. Since this not a good option for us, let's skip it.
Second, if the ViewModel is decorated with a ViewAttribute, the specified view will be created. This is relatively easy, but it clutters your ViewModel with an attribute and I don't like it.
Third, specified assemblies will be searched to find the matching view according to a specified naming convention. This sound interesting, let's use this method.
Fourth, if you don't like any of these behaviors, you can plug in your own IViewStrategy implementation.

If you remember, we've created an empty Views folder. If you create a UserControl named ShellView (mind the naming), Caliburn will automagically pick it up as the View for our ShellViewModel. How is this done, you may ask? According to pre-defined naming rules, Caliburn will look in folders named Presenter, Model, ViewModel and PresentationModel to create a ViewModel instance, and to create a View instance, it will look for it in the Views folder. An example might clear it up a little bit. Supposing you have an IShellPresenter, the implementation would be named ShellPresenter in the folder named Presenters. You should name the view for this presenter ShellView and place it in Views folder. The ViewModel names refers to different implementation of Presentation Model design pattern, but those terms are used interchangeably in Caliburn.

So, we're going to use the naming convention (fourth method). Let's create an empty UserControl named ShellView and put it in Views folder:

<UserControl x:Class="PayRoll.Views.ShellView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    
</UserControl>

You can run the application now and it works. Caliburn has created a View (UI) and a POCO class as ViewModel and set the DataContext property of the View to the instance of the ViewModel. If you've noticed, we've set a UserControl as our root View. While you can create a Window object as your root View, if you create a UserControl (or anything other than a Window), Caliburn will create a MainWindow for you and place the View object as its content. This behavior is for Caliburn v1.1 so if you're using older version 1.0 you can either upgrade or use a Window as your root view.

Binding

To check if View and ViewModel are really bound together, let's create a commmand on the ViewModel and invoke it from the View. When invoked, it will change a Message property on the ViewModel. So first, open the IShellViewModel interface and add the ICommand and Message properties to the interface definition:

    public interface IShellViewModel
    {
        /// <summary>
        /// A command that says hello when invoked.
        /// </summary>
        ICommand SayHelloCommand { get; }

        /// <summary>
        /// Message
        /// </summary>
        string Message { get; set; }
    }

...and implement the command property on your ShellViewModel class. To facilitate command handling, we'll use a DelegateCommand class (originally RelayCommand) introduced by Josh Smith. Then instead of just displaying a MessageBox, let's Create a TextBlock and bind it to the Message property on our ViewModel. When binding some element to a property on the ViewModel, we need to implement INotifyPropertyChanged interface on the ViewModel. Fortunately, there's a base class in Caliburn which does exactly that:

    public class ShellViewModel : PropertyChangedBase, IShellViewModel
    {
        private ICommand _sayHelloCommand;
        private string _message;

        public virtual ICommand SayHelloCommand
        {
            get
            {
                if (_sayHelloCommand == null)
                    _sayHelloCommand = new DelegateCommand(SayHello);

                return _sayHelloCommand;
            }
        }

        public virtual string Message
        {
            get { return _message; }
            set
            {
                _message = value;
                NotifyOfPropertyChange("Message");
            }
        }

        private void SayHello()
        {
            Message = "Greetings from Caliburn!";
        }
    }

...Finally, let's place a Button and a TextBlock on the View and bind those to our ViewModel:

<Window x:Class="PayRoll.Views.ShellView"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" Width="320" Height="200" >
    <StackPanel>
        
        <Button Command="{Binding Path=SayHelloCommand}" Content="Say Hello"  />
        
        <TextBlock Text="{Binding Path=Message}" FontSize="16" FontWeight="Bold" />
        
    </StackPanel>
</Window>

In next post, I'll show you how to add DevExpress components to the pot and how to create a re-usable shell and along the way. We'll see how to host other ViewModels in our ShellView and how to manage them. You can get the source code of this part from here.

Entity Framework 4 - Part Three : Repository Pattern

HEskandari — Sat, 12 Dec 2009 14:27:00 GMT

Last post showed how to use a “ObjectContext” derivation to automatically generate audit information. Now instead of using a “ObjectContext” directly, a rather different approach, a pattern called “Repository Pattern” is used to encapsulate access to the entities.

Note: I’m using the bits included in Visual Studio 2010 Beta 2 with additional features included in Entity Framework 4 CTP 2 (not included in VS 2010) which you can download here.

Specification Pattern

What is “Specification Pattern” and what does it have to do with “Repository Pattern”? In simple terms, a specification is a piece of business logic that specifies if an entity is matching a certain criteria. Let’s suppose we need to fetch list of high profile Customers. We can hard code this criteria in UI code behind which is a bad practice you probably agree. We can also place this on our entity class, the “Customer”. This may not seem so bad. Maybe it is even a good practice to build the business logics like these into the entity, right? But this will only lead to a polluted interface on our entity class as more business logic is introduced. Using “Specification Pattern” and Separation of Concerns, these pieces of business logic can be placed in a separate class where they belong. Later, we'll pass this criteria as a parameter into the repository to specify which entities we want to be returned.

The Specification interface we're going to use would look like this:

    public interface ISpecification<TEntity> where TEntity : EntityBase
    {
        Expression<Func<TEntity, bool>> IsSatisfied { get; }
    }

...and implementation for our example above would be this:

    public class HighProfileCustomersSpecification : ISpecification<Customer>
    {
        public Expression<Func<Customer, bool>> IsSatisfied
        {
            get 
            {
                return c => c.Orders.Count > 50;
            }
        }
    }

Generic Repository

First let’s specify an interface for our repository. We need generic method like FindByKey, Save, Update and methods that accept an ISpecification parameter like FindOne and FindMany.

    public interface IRepository<TEntity> where TEntity : EntityBase
    {
        /// 
        /// Saves the transient entity.
        /// 
        TEntity Save(TEntity entity);

        /// 
        /// Updates the existing entity.
        /// 
        TEntity Update(TEntity entity);

        /// 
        /// Finds the entity by its key.
        /// 
        TEntity FindByKey(long id);

        /// 
        /// Finds entities based on provided criteria.
        /// 
        IList<TEntity> FindMany(ISpecification<TEntity> criteria);

        /// 
        /// Finds one entity based on provided criteria.
        /// 
        TEntity FindOne(ISpecification<TEntity> criteria);
    }

Let’s start with the easiest one, FindByKey method. To find an entity an ObjectContext that exposes the entity using IObjectSet<TEntity> is needed so in our generic repository, we’ll create those.

    public abstract class Repository<TEntity> : IRepository<TEntity> where TEntity : EntityBase
    {
        private readonly ObjectContext _context;
        private readonly ObjectSet<TEntity> _entity;

        protected Repository(ObjectContext context)
        {
            _context = context;
            _entity = Context.CreateObjectSet<TEntity>();
        }

        protected ObjectContext Context
        {
            get { return _context; }
        }

        protected IObjectSet<TEntity> Entity
        {
            get { return _entity; }
        }
    }

With this a lot of our implementation would just call the related method on Entity property.

    public TEntity FindByKey(long id)
    {
        return Entity.Where(x => x.Id == id)
                         .FirstOrDefault();
    }

For Save and Update methods, the ObjectContext does provide a method that has a parameter accepting a fully qualified entity name. What’s FQEN, you may ask? Each object that is in a EntityFramework container has a fully qualified name which is in “ContainerName.EntityName” format. These are the MetaData information that is exposed through EntitySet property and usually are stored in the .edmx file which we don't have because we're using the "All Code" feature, remember? Fortunately, there is one place that we can get the EntitySet metadata for our POCO entity and that is through the ObjectSet instance.

    private string GetEntityName()
    {
        return string.Format("{0}.{1}", _entity.EntitySet.EntityContainer, _entity.EntitySet.Name);
    }

Now it is possible to write the generic Save and Update methods as follows:

    public TEntity Update(TEntity entity)
    {
        var fqen = GetEntityName();

        Context.ApplyCurrentValues(fqen, entity);
        Context.SaveChanges(SaveOptions.AcceptAllChangesAfterSave);

        return entity;
    }

    public TEntity Save(TEntity entity)
    {
        var fqen = GetEntityName();

        Context.AddObject(fqen, entity);
        Context.SaveChanges(SaveOptions.AcceptAllChangesAfterSave);

        return entity;
    }

Note: I’ve wraped the call to SaveChanges in Save and Update methods. You can provide additional SaveChanges method in the repository that will be called explicitly by the code that uses the repository instance.

For remaining query methods that return one or multiple instances of the Entity, we’ll use the generic CreateQuery method on the ObjectContext and feed the ISpecification’s criteria to the Where method.

    public TEntity FindOne(ISpecification<TEntity> spec)
    {
        var entityName = GetEntityName();
        var query = _context.CreateQuery<TEntity>(entityName)
                                      .Where(spec.IsSatisfied());

        return query.FirstOrDefault();
    }

    public IList<TEntity> FindMany(ISpecification<TEntity> spec)
    {
        var entityName = GetEntityName();
        var query = _context.CreateQuery<TEntity>(entityName)
                                     .Where(spec.IsSatisfied());

        return query.ToList();
    }

That sums it up. Our concrete repositories are now just a breeze to create. We can build any missing fine grained methods into our concrete repository using the Entity property. With this approach, you only need one Repository per each Aggregate Root and EF4 will take care of any related transient child entities that should be persisted when aggregate root is saved.

    public interface ICustomerRepository : IRepository<Customer>
    {
        IList<Customer> NewlySubscribed();
    }

    public class CustomerRepository : RepositoryBase<Customer>, ICustomerRepository
    {
        public CustomerRepository(ObjectContext context) 
            : base(context)
        {
        }

        public IList<Customer> NewlySubscribed()
        {
            var lastMonth = DateTime.Now.Date.AddMonths(-1);
            return base.Entity.Where(c => c.Inserted >= lastMonth)
                            .ToList();
        }
    }

You can get the whole project containing complete API from here.

EntityFramework 4 – Part Deux : Audit Info

HEskandari — Tue, 08 Dec 2009 15:24:00 GMT

In last post showed how easy it was to use POCO classes in EntityFramework v4, a feature called “All Code”. This new feature, facilitates creating domain models but how about other features you may already have using other ORMs like NHibernate? Let’s see how we can achieve automatic audit logging in EF v4.

Note: I’m using the bits included in Visual Studio 2010 Beta 2 with additional features included in Entity Framework 4 CTP 2 (not included in VS 2010) which you can download here.

For running Linq queries, we probably already have an existing “ObjectContext” implementation (see previous post). The “ObjectContext” class provides. To create audit log, we need to tap into “SavingChanges” event and populate audit properties. Having an “EntityBase” class as layer super-type that contains “Inserted”, “InsertedBy”, “Updated” and “UpdatedBy” audit fields we can add this cross cutting concern, across all of our entities which is what I’ve done here, but obviously instead of using a base class, you can do this with an Interface. Let’s create an “AuditableObjectContext” which will do the auditing part when the entity is saved by either an Update or an Insert:

public class AuditableObjectContext : ObjectContext
{
    public AuditableObjectContext(EntityConnection connection) : base(connection)
    {
        SubscribeEvents();
    }

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            UnSubscribeEvents();
        }

        base.Dispose(disposing);
    }

    private void SubscribeEvents()
    {
        SavingChanges += OnSavingChangesCore;
    }

    private void UnSubscribeEvents()
    {
        SavingChanges -= OnSavingChangesCore;
    }

    private void OnSavingChangesCore(object sender, EventArgs e)
    {
        OnSavingChanges();
    }

    public virtual void OnSavingChanges()
    {
        FillAuditFields();
    }

    private void FillAuditFields()
    {
        var stateManager = ObjectStateManager;
        var inserted = stateManager.GetObjectStateEntries(EntityState.Added);
        var modified = stateManager.GetObjectStateEntries(EntityState.Modified);

        inserted.Where(x => x.Entity is EntityBase).Select(x => x.Entity).Cast<EntityBase>().ForEach(x =>
        {
            x.Inserted = DateTime.Now;
            x.InsertedBy = Thread.CurrentPrincipal.Identity.Name;
        });

        modified.Where(x => x.Entity is EntityBase).Select(x => x.Entity).Cast<EntityBase>().ForEach(x =>
        {
            x.Updated = DateTime.Now;
            x.UpdatedBy = Thread.CurrentPrincipal.Identity.Name;
        });
    }
}

Our existing “SalesObjectContext” class from previous post, now looks like this:

public class SalesObjectContext : AuditableObjectContext
{
    public SalesObjectContext(EntityConnection connection)
        : base(connection)
    {
    }

    public IObjectSet<Category> Categories
    {
        get { return CreateObjectSet<Category>(); }
    }

    public IObjectSet<Product> Products
    {
        get { return CreateObjectSet<Product>(); }
    }
}

It was pretty easy and painless to create auditing fields, don’t you think? In the next post, we'll see how to implement repository pattern using POCO mode and EF v4.