As I said in the previous post, this post should be about the OrderView. This view should allow users to pick items from a list of products, add them to the actual order, choose quantities, view the current total price and submit the order. Also the user should be able to filter, sort and do pagination on the product list. I’m sure you’ve seen enough blog posts from other people talking about this subject, that is getting the selected product, add it to another collection or create an order detail based on it, then update some other data on the UI and finally submit the changes back to the server. The thing is, everyone has its own way for programming and eventually when you end up in a team, you may find that two people coded the same thing in a different way, and one has a bug in situation A and the other has a bug in situation B. Having a good MVVM framework with a well defined methodology is a must to prevent these situations. In this post I want to talk about essential components you must have in an MVVM framework. Later, I’ll describe an MVVM Framework I’ve been working on which was based on WCF RIA Services but doesn’t really depend on it.

Since we’re following best practices, we know that using a good MVVM architecture we can come up with a solution whose fetching, filtering, sorting, paging logic is entirely separated from the view, allowing us to also have different views for the same view model. For example, we can start by using a DataGrid and a DataPager to display our items but later provide a new view that uses comboboxes to select the sort options, an album-like listbox to show the items and custom buttons for paging. Also, we should be able to separate all this logic from its actual data access logic to be able to use mock objects for our model and do unit tests for our viewmodels. That’s not an easy task but that’s what I want to achieve from now on.

Well, to start, .NET / Silverlight already offers us some classes and interfaces that are very handy for MVVM scenarios.

• INotifyPropertyChanged – Used to raise an event when a property changes. WPF / Silverlight Binding framework use this interface to update the view when a property changes.
• INotifyCollectionChanged – Used to raise an event when an insert, remove, clear or replace operation has been done against a collection. WPF / Silverlight controls that have an ItemsSource property usually use this interface to create or delete visual items in a container. For example, ListBoxes display new ListBoxItems, DataGrids display new DataGridRows.
• ICollectionView – Used to provide filter, sort descriptions, group descriptions, and item selection for an IEnumerable collection and have the view display only the filtered items, sorted according to the sort descriptions and highlight the selected item. (Has more features but these are the most relevant for the sake of this post).
• IPagedCollectionView – Used to provide paging options to an IEnumerable collection. This is used by DataPagers mostly, that make calls to the MoveToPage(int pageIndex) method and allows us to register in the PageChanging event and fetch a new page of entities to be displayed.
• There are other important interfaces like IEditableObject, IEditableCollectionView but I’m not going to cover those in this posts. They are used to update property values of an object in an atomic fashion.

Unfortunately, WCF RIA Services collections do not implement ICollectionView or IPagedCollectionView so we have to provide our own mechanism for filtering, sorting and paging data. However, this is fairly easy to do with LINQ and Expressions and we can compose queries with some LINQ operators with WCF RIA Services. Silverlight has its own implementation of IPagedCollectionView, called System.Windows.Data.PagedCollectionView but it was designed to work with in-memory collections and not server-side “collections” (data sources). In this series I’m providing my own IPagedCollectionView/ICollectionView implementation which I’ve designed to work with any kind of data sources. Whatever option is used is entirely up to the Model in MVVM.

So lets see how my MVVM Framework works.

First of, we have the model concept:

public interface IDomainModel : IDisposable
{
    void RejectChanges();
    ISubmitOperation SaveChanges();
    ISubmitOperation SaveChanges(Action<ISubmitOperation> callback, object userState);

    IDomainQuery<T> GetQuery<T>();

    void Add<T>(T entity);
    void Remove<T>(T entity);
    void Attach<T>(T entity);
    void Detach<T>(T entity);

    bool HasChanges { get; }
    bool IsSubmitting { get; }
    bool IsLoading { get; }
}

If you’re familiar with the DomainContext API, you’ll find this interface very easy to understand. This model interface is supposed to provide you with basic functionality for retrieving data, change it and save it. For more specific operations, you can extend this interface, add specific operations and have your viewmodel depend on it.

The IDomainQuery interface represents a query against a certain entity type repository (whatever that may be). As a query, it allows you to filter, sort and page the data.

public interface IDomainQuery : IDisposable
{
    void Cancel();
    void Load();

    event Action Loading;
    event Action<ILoadOperation> Loaded;
    event Action Canceled;
}

public interface IDomainQuery<T> : IDomainQuery
{
    /// <summary>
    /// Delegate that returns a lambda expression to apply in a Where operation
    /// </summary>
    Func<Expression<Func<T, bool>>> FilterExpression { get; set; }

    /// <summary>
    /// SortDescription values that are applied in a OrderBy/ThenBy operation
    /// </summary>
    Func<SortDescriptionCollection> SortDescriptions { get; set; }

    /// <summary>
    /// Contains the required data that are applied in a Skip and Take operation
    /// </summary>
    Func<PageDescription> PageDescription { get; set; }

    new event Action<ILoadOperation<T>> Loaded;
}

public sealed class PageDescription
{
    public int PageSize { get; set; }
    public int PageIndex { get; set; }
}

Besides, it has events to let you know when it is has begun and completed the load operation. There are two important things to note in the IDomainQuery interface. First is the fact that the way you filter an IDomainQuery is how you filter a RIA Services EntityQuery and how you filter any IQueryable object. That means it’s very easy to do IDomainQuery implementations that query in-memory repositories or server-side repositories (note that EntityQuery doesn’t implement IQueryable and it’s not easy to integrate both concepts). The other important thing is that the filter, sort, page mechanism is based on delegates which means that whenever the query is executed/reexecuted these delegates are always reevaluated and will always reflect your viewmodel’s current state.

Last but not least, we have the operations. I’ve created interfaces for Load and Submit operations. I’ve implemented all these interfaces with classes that rely on WCF RIA Services. I’m not going to post the code of those classes but they’re available in the source code repository so you can take a look.

If you’re familiar with DomainContext your’re probably wondering where are the EntitySets and where do you manipulate collections. Well, since my IDomainModel implementation relies on WCF RIA Services, you can extend that class and manipulate your DomainContext to implement any operation that you want to make available in your extended IDomainModel. But with this framework they’re not supposed to be accessed in your viewmodel. Instead, I use my ICollectionView implementation, which I called DomainCollectionView.

public interface IDomainCollectionView : ICollectionView, IPagedCollectionView, INotifyPropertyChanged
{
    void Add(object item);
    void Remove(object item);
}

public interface IDomainCollectionView<T> : IDomainCollectionView, IEnumerable<T>
{
    void Add(T item);
    void Remove(T item);
}

The actual implementation relies on an IDomainQuery and will be a view for the results that are fetched in every operation. Since you can implement an IDomainQuery for any IEnumerable you can use this implementation for any data source.

public class DomainCollectionView<T> : ViewModelBase, IDomainCollectionView<T>
{
    private IDomainQuery<T> query;
    private ObservableCollection<T> sourceCollection;

    #region DomainCollectionView Members

    public DomainCollectionView(IDomainQuery<T> query, bool usePaging = true)
    {
        this.query = query;
        this.sourceCollection = this.CreateSourceCollection();
        this.CurrentItem = null;
        this.CurrentPosition = -1;

        //Apply sort and paging
        query.SortDescriptions = () => this.SortDescriptions;
        if (usePaging)
        {
            this.canChangePage = true;
            this.pageSize = 10;// default page size to 10
            query.PageDescription = () => new PageDescription { PageSize = this.PageSize, PageIndex = this.PageIndex };
        }

        query.Loaded += this.OnDataRefreshed;
    }

    private void OnDataRefreshed(ILoadOperation<T> loadOp)
    {
        using (this.DeferRefresh())
        {
            this.sourceCollection.Clear();
            foreach (var entity in loadOp.Entities)
                this.sourceCollection.Add(entity);

            this.ItemCount = loadOp.TotalEntityCount;
            this.TotalItemCount = loadOp.TotalEntityCount;
        }
    }

    //...
}

Now that I’ve introduced the model and the IDomainCollectionView, it is time we talk a bit about the viewmodel.

Unlike the model, viewmodels aren’t much reusable because they usually depend on the view’s needs. However, a lot of views in LOB apps have common needs: searching/listing entities, editing entities, create associations between entities. We can create viewmodels for these concepts and extend them only to implement business logic. All the infrastructure and plumbing can be centralized and reused everywhere.

In the next post I want to talk about how we can create base viewmodels for these concepts. But before we finish, I’ll leave just an initial thought on a base viewmodel that can be used to search/list entities.

public class ListVM<T> : ViewModelBase, IListVM<T>
{
    private IDomainModel model;

    public ListVM() { }

    protected virtual IDomainModel CreateModel()
    {
        return ServiceLocator.Current.GetInstance<IDomainModel>();
    }

    public void Initialize(IListVMInitializeArgs args)
    {
        this.model = args.ExistingModel ?? this.CreateModel();
        var query = model.GetQuery<T>();
        this.Entities = new DomainCollectionView<T>(query, args.RequiresPaging);
        query.Load();
    }

    public IDomainCollectionView<T> Entities
    {
        get;
        private set;
    }
}

With just a few lines of code, we have a base viewmodel that can:

• Display results from a query that can be sorted and paged on the server. Just bind a datagrid to the Entities collection and play with it.
• Reuse an existing model or create a new one. The current implementation can use a shared model for the whole app that is registered in the current Dependency Injection container or let a derived viewmodel decide what to do.

I’ll let you think about it. In the next post I’ll dive deeper and add a lot more functionality in these viewmodels.

See you soon,

Happy coding.

When building composite LOB silverlight apps you should be aware that modularity is an important requirement. As a developer it should be easier for you to mantain your code and add new features to your application without having to change the rest, plus your application’s XAP file doesn’t grow bigger. Every module is a separate XAP file, that can be downloaded on demand, depending on the user’s intent to use a certain functionallity.

Below is one possible architecture to achieve what we need.

The Shell folder contains the main xap, which I called MyApp. This xap is only responsible for downloading others and provide means for them to display its content inside the main application. The Modules folder contains 4 essential modules for the business scenario I’ve defined in a previous post. The Orders module allows non-employee users to fullfil new orders. The Sales module allows employees to view pending orders and process them. The statistics module allows employees to view charts and reports of sales evolution. Features for human resources department are accomplished by the Administration module, which also should allow application users to be created and/or managed. Modules and the Shell are compiled to MyApp.Web’s ClientBin folder.

The Infrastructure project is a key piece. It defines ways to communicate between modules (modules don’t reference other modules) and between the main application. In other words, it is a common contract shared by the modules. When it is defined or partially defined, module development can start. Notice that the development of the Orders module doesn’t depend on the development of the Sales module or the Statistics module, which means that different people can work on each one.

MyApp.Data.Silverlight is a project that should have WCF RIA Services generated code, plus other service clients which are used by modules.

The Server layer corresponds to the architecture I’ve defined in the first post.

So how does our Shell download the modules? We just need to specify a module catalog and give it to PRISM’s Bootstrapper which is responsible for initializing PRISM’s framework. Below is the module catalog I’ve defined for this scenario.

<prism:ModuleCatalog xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:sys="clr-namespace:System;assembly=mscorlib"
    xmlns:prism="clr-namespace:Microsoft.Practices.Composite.Modularity;assembly=Microsoft.Practices.Composite">

    <prism:ModuleInfo Ref="MyApp.Modules.Administration.xap"
                      ModuleName="Administration"
                      ModuleType="MyApp.Modules.Administration.Module, MyApp.Modules.Administration, Version=1.0.0.0"
                      InitializationMode="WhenAvailable">
    </prism:ModuleInfo>

    <prism:ModuleInfo Ref="MyApp.Modules.Statistics.xap"
                      ModuleName="Statistics"
                      ModuleType="MyApp.Modules.Statistics.Module, MyApp.Modules.Statistics, Version=1.0.0.0"
                      InitializationMode="WhenAvailable">
    </prism:ModuleInfo>

    <prism:ModuleInfo Ref="MyApp.Modules.Sales.xap"
                      ModuleName="Sales"
                      ModuleType="MyApp.Modules.Sales.Module, MyApp.Modules.Sales, Version=1.0.0.0"
                      InitializationMode="WhenAvailable">
    </prism:ModuleInfo>

    <prism:ModuleInfo Ref="MyApp.Modules.Orders.xap"
                      ModuleName="Orders"
                      ModuleType="MyApp.Modules.Orders.Module, MyApp.Modules.Orders, Version=1.0.0.0"
                      InitializationMode="WhenAvailable">
    </prism:ModuleInfo>
</prism:ModuleCatalog>

Notice the InitializationMode attributes. It allows us to specify wether the modules should be downloaded as soon as possible or on demand. For now, I want my modules to download as soon as possible but later I’ll show effective techniques to download them on demand. However, that doesn’t affect the way I build them.

To start, our Shell can have a top bar displaying a hello message, a menu on the left and a region where modules can display its content.

    <Border BorderThickness="5" CornerRadius="10">
        <tlk:DockPanel LastChildFill="True">
            <shellWelcome:WelcomeBar tlk:DockPanel.Dock="Top" Margin="5"/>
            <shellMenu:Menu tlk:DockPanel.Dock="Left" VerticalAlignment="Stretch" Margin="5,0,5,5"/>
            <shellContainer:MainContainer Margin="0,0,5,5"/>
        </tlk:DockPanel>
    </Border>

The visual result is something like this:

I’d like the menu and the main container to be dynamic, in other words, have its content set dinamically by modules instead of being defined in the controls itself.

We could create an interface like IMenu, implemented by our Menu’s viewmodel and use it by modules to display content. While that seems to be a decoupled aproach because your modules can display its content without depending on the menu control itself, it is actually coupled to the object that will implement the IMenu interface. That means that if you want to display your menu options in other places, like a toolbar or a ribbon bar, you will need another interface to interact with those controls. A solution to this problem is to use a message publisher/subscriber technique relying on a mediator object, that is PRISM’s EventAggregator. Now what you do is publishing a message saying “I want to display this menu option” and which ever control that is interested in showing menu options subscribes that message and acts accordingly. Lets see how we can do that:

public class MenuOptionMessage : CompositePresentationEvent<MenuOptionMessageArgs> { }

public class MenuOptionMessageArgs
{
    public ICommand Command { get; set; }
    public string Text { get; set; }
    public string ImageSourceUri { get; set; }

    public string Group { get; set; }
}

The MenuOptionMessage is a PRISM event whose payload is a MenuOptionMessageArgs message. So whenever you want to publish a MenuOptionMessage you create a MenuOptionMessageArgs and tell the EventAggregator to broadcast it to every subscriber. The EventAggregator can be accessed through dependency injection or the IoC container. I usually create a simple utility class to keep the code cleaner:

public class Messenger
{
    public static T Get<T>()
        where T : EventBase
    {
        var ev = ServiceLocator.Current.GetInstance<IEventAggregator>();
        return ev.GetEvent<T>();
    }
}

Now we can have our modules publish MenuOptionMessages.

Order Module initialization:

Messenger.Get<MenuOptionMessage>().Publish(new MenuOptionMessageArgs
{
    Command = Commands.NewOrderCommand,
    Text = "Create New Order",
    Group = "Orders"
});
Messenger.Get<MenuOptionMessage>().Publish(new MenuOptionMessageArgs
{
    Command = Commands.ViewOrdersCommand,
    Text = "View Orders",
    Group = "Orders"
});

Sales module initialization:

Messenger.Get<MenuOptionMessage>().Publish(new MenuOptionMessageArgs
{
    Command = Commands.ViewPendingOrdersCommand,
    Text = "Pending Orders",
    Group = "Sales"
});
Messenger.Get<MenuOptionMessage>().Publish(new MenuOptionMessageArgs
{
    Command = Commands.ViewProcessedOrdersCommand,
    Text = "Processed Orders",
    Group = "Sales"
});

The Menu control displays every command grouped by its Group and creates an expander for each Group. You can access the source code to confirm that.

Now what we need to do is have our commands display views.

PRISM has a region concept, where you define regions within your Shell, give them a name and then your modules inject views into those regions by specifying the name. I’m no fan of this feature because it creates tight coupling between views and regions. Besides this means that your screen logic only works with PRISM. I usually use a different approach, which allows us to also use PRISM regions but other UI frameworks as well. Besides, it is not that hard to build your own UI framework, if you keep it simple. For example, instead of thinking on regions, think about view positions.

public enum ViewPosition
{
    Left,
    Right,
    Top,
    Bottom,
    Center,
    Floating
}

Using the same technique we did for the Menu, whenever we want to display a view, we simply have to publish a message where we specify the position and the view itself and whoever is responsible to display that view in the specified position should subscribe the message and act accordingly. These messages should be defined in the Infastructure assembly. Lets see how the message is defined:

public class CreateViewMessage : CompositePresentationEvent<CreateViewMessageArgs> { }

public class CreateViewMessageArgs
{
    public Lazy<object> View { get; set; }
    public ViewPosition Position { get; set; }
    public string Title { get; set; } //optional
}

Notice the Lazy object there. That allows you to have your view created by the subscriber instead of being created by the publisher. That allows you to use different threads when publishing/subscribing, although in this case the subscriber should use the UI thread.

Below is an example of how to publish a CreateViewMessage from the Order module.

public class Commands
{
    public static ICommand NewOrderCommand = new ActionCommand(Commands.NewOrder);
    public static ICommand ViewOrdersCommand = new ActionCommand(Commands.ViewOrders);

    private static void NewOrder()
    {
        Messenger.Get<CreateViewMessage>().Publish(new CreateViewMessageArgs
        {
            View = new Lazy<object>(() => ServiceLocator.Current.GetInstance<OrderView>()),
            Position = ViewPosition.Center,
            Title = "New Order"
        });
    }

    private static void ViewOrders()
    {
        //to be implemented
    }
}

Notice the OrderView being created by the ServiceLocator to allow dependency injection, if needed.

The MainContainer control is responsible for subscribing this message and display the view inside a tab control.

public partial class MainContainer : UserControl
{
    public MainContainer()
    {
        InitializeComponent();
        if (DesignerProperties.IsInDesignTool)
            return;

        Messenger.Get<CreateViewMessage>().Subscribe(this.HandleCreateView, ThreadOption.UIThread, true, this.CanHandleCreateView);
    }

    private bool CanHandleCreateView(CreateViewMessageArgs args)
    {
        return args.Position == ViewPosition.Center;
    }

    private void HandleCreateView(CreateViewMessageArgs args)
    {
        this.tabCtrl.Items.Add(new TabItem
        {
            Header = args.Title, Content = args.View.Value,
            VerticalContentAlignment = System.Windows.VerticalAlignment.Stretch,
            HorizontalContentAlignment = System.Windows.HorizontalAlignment.Stretch
        });
    }
}

When you subscribe a message you can specify a predicate that tells the publish mechanism wether you really want to handle that message. In this case, the main container only wants to handle CreateViewMessages that have views to be displayed in the Center position. I could have another component subscribing the CreateViewMessage and display views inside windows whenever the position is Floating. The ThreadOption parameter is also important. Every message that deals with UI should be subscribed in the UI Thread. If you want to plug in a logger to subscribe/log messages you don’t need to subscribe on the UI thread. In that case you should use a background thread.

This is a very simple aproach on how to do UI composition which works and is very effective. The source code repository has been updated as well.

In the next post I will focus on viewmodels and how we can build the OrderView.

First what we have to do is create a buddy class as described in the following example:

[MetadataType(typeof(Customer.CustomerMetadata))]
public partial class Customer
{
    internal class CustomerMetadata
    {
        [Display(ResourceType = typeof(Metadata), Name = "MyApp_Customer_Number")]
        public int Number;

        [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Email")]
        public string Email;

        [Include]
        public EntityCollection<Order> Orders;
    }
}

[MetadataType(typeof(Employee.EmployeeMetadata))]
public partial class Employee
{
    internal class EmployeeMetadata
    {
        [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Name")]
        [StringLength(128, ErrorMessageResourceType = typeof(Metadata), ErrorMessageResourceName = "CommonErrors_StringLength")]
        public string Name;

        [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Email")]
        public string Email;

        [Include]
        public Department Department;
    }
}

The DisplayAttribute attribute is very useful, as it annotates your properties with information that can be consumed in various ways. For example, when using your entity in a Datagrid, the cell headers will automatically look up for DisplayAttributes and retrieve the localized string for that property. The same applies for labels in a Dataform and if you want to create your own UI framework, you can leverage this type of annotation to start localizing your app. Notice how I’ve reused some resource names for common properties like Email. The same could have been done for Number and Name, but that really depends on each case.

You can place validation rules on your properties as well using attributes like StringLength, apply regular expressions or even create your own custom validation rules. The great part about this is that those rules will be available in the client as well. The DomainService makes sure that before executing operations on entities all the validation rules are applied. Note that you can’t do all kinds of validation on your entities using metadata. Some validations may require connecting to a database, transactions, etc, and such information isn’t available in this type of validation context. I recommend that such validations are performed after DomainService’s ExecuteChangeSet is invoked and right before the PersistChangeSet method.

More on metadata specification can be found in the documentation or other resources on the web. I just want to focus on a different aspect that not many people tend to write about. That is sharing the Resources in the client and the server. The client project will not compile if the ResourceManager Metadata isn’t available. Since it is defined on the server, you should follow these steps in order to enable it on the client:

• Add the resource files as a link to the client project
• Change your client project’s default namespace to the same namespace that is defined in the server project that holds the resource files
• Change the client project’s .csproj where it references the linked Designer.cs file and add these lines of code:

  <Compile Include=”..\..\..\Server\Data\MyApp.Data\Resources\Metadata.Designer.cs”>

        <AutoGen>True</AutoGen>      <Link>Resources\Metadata.Designer.cs</Link>

        <DesignTime>True</DesignTime>

        <DependentUpon>Metadata.resx</DependentUpon>

  </Compile>

• Make sure the resource files have the same relative path in the client project as in the server project. In this case, I’ve created a Resources folder in both projects.
• Also make sure that the resource file has Public marked as its Access Modifier.

These steps are necessary because adding linked files for dependent files, like Medatata.resx / Metadata.Designer.cs won’t automatically mark them as dependent, so you need to do it manually.

Now you should be able to compile your application and start taking advantage of metadata in your entities.

To finish, I’d like to say that all the code is available at http://code.google.com/p/mfelicio-wordpress under trunk/2010/SL-MVVM-RIA. I’m sorry for the delay on this one.

Next posts will be covering client development.

In the previous post I described an overview of an architecture that could be used when developing silverlight modular apps. In this post I’ll start with a simple business domain model and create a domain layer around that model.

In this example our app will be a web application for a company that sells products and that can be used by its customers to fulfill orders and its employees to process them. These orders have details which consist of products and quantities. Each product can have a product category. When a customer submits an order fulfillment, an employee of the company may process that order to prepare the items for shipping.

The company has a few departments, and each employee belongs to a department. This means that employees from the Sales department will be to process orders; employees from the Human Resources department will be able to recruit new employees; and employees from the Financial Department will be able to watch some charts and print reports with statistics of how sales are evolving as time goes by, sales reports, etc.

Authentication and authorization will be added in the future.

For the sake of simplicity, I’ve create the following data model.

This model will be both our data model and domain model. It is very simple and as I said in the previous post, creating a separate domain model is optional because you can still do fine with your data entities. Since we’re using Entity Framework we’ll take advantage of LinqToEntitiesDomainService, a specific Domain Service that deals with EF’s objects.

Since we’re starting with our Domain layer, we’ll define a Domain Service that can be used from our Silverlight app (or other clients as well) and create the CRUD operations. I’m sure you have noticed how much (duplicated) code is generated when you use the Domain Service template from Visual Studio. Well.. suffer no more! Just create a base class for your domain services and add the following methods:

#region Basic CRUD
protected IQueryable<T> GetQuery<T>()
    where T : class
{
    return this.GetRepository<T>().GetQuery();
}
protected void Insert<T>(T entity)
    where T : class
{
    this.GetRepository<T>().Add(entity);
}
protected void Update<T>(T entity)
    where T : class
{
    this.GetRepository<T>().AttachAsModified(entity, this.ChangeSet.GetOriginal(entity));
}
protected void Delete<T>(T entity)
    where T : class
{
    this.GetRepository<T>().Delete(entity);
}
#endregion

protected IRepository<T> GetRepository<T>()
    where T : class
{
    return this.Container.Resolve<IRepository<T>>();
}

The Container property is an IUnityContainer instance, that I keep on the base Domain Service. I usually have a common singleton class where the IoC container is available but I also create a child container for each Domain Service. That allows me to register specific instances in the child container and use it only within the scope of my Domain Service. This is useful for resolving repositories because my repositories depend on the ObjectContext which gets injected via dependency injection. This is how it’s done:

public abstract class DomainRepositoryService<TContext> : LinqToEntitiesDomainService<TContext>, IDbContextManager
    where TContext : ObjectContext, IDbContext, new()
{
    protected IUnityContainer Container { get; private set; }
    /// <summary>
    /// Create a child container to use THIS as the IDbContextManager implementation when resolving repositories
    /// Ensures that other threads / domain services can use the main container to resolve repositories
    /// and use its own instance as the IDbContextManager for the repositories they need
    /// </summary>
    /// <param name="context">The DomainServiceContext instance</param>
    public override void Initialize(DomainServiceContext context)
    {
        base.Initialize(context);

        this.Container = IoC.Current.Container.CreateChildContainer();
        this.Container.RegisterInstance<IDbContextManager>(this);
    }

    #region IDbContextManager Members
    public IDbContext GetDbContext()
    {
        return this.ObjectContext;
    }
    #endregion
    //...
}

That said, the specific Domain Service for our Silverlight app will look like this:

[EnableClientAccess()]
public class MyAppService : DomainRepositoryService<MyAppEntities>
{
    #region Customer
    public IQueryable<Customer> GetCustomers()
    {
        return base.GetQuery<Customer>();
    }
    public void InsertCustomer(Customer entity)
    {
        base.Insert(entity);
    }
    public void UpdateCustomer(Customer entity)
    {
        base.Update(entity);
    }
    public void DeleteCustomer(Customer entity)
    {
        base.Delete(entity);
    }
    #endregion
    //repeat for the other entities...
}

Notice how my Domain Layer doesn’t really care how entities are stored or managed with EF. It simply delegates that responsability to an object that implements the IRepository interface.

This interface can be generic and often looks like:

public interface IRepository<TEntity>
    where TEntity : class
{
    TEntity GetEntity(int id);
    IQueryable<TEntity> GetQuery();
    void Add(TEntity entity);
    void Update(TEntity entity);
    void Delete(TEntity entity);
    /// <summary>
    /// Abstraction on RIA's AttachAsModified extension method
    /// </summary>
    /// <param name="current"></param>
    /// <param name="original"></param>
    void AttachAsModified(TEntity current, TEntity original = null);
}

For simplicity I’ve included the AttachAsModified method in the IRepository. This method is important because RIA requires that the current entity being updated be attached in the ObjectContext.  Another option would be to create a separate interface that derives from IRepository and add the method there. That’s because the IRepository interface is a generic concept that can be used with many data access technologies.

Note that from the moment you create your Domain Service and expose your entities, imediately another person/team can start building the app using the exposed entities, while another team keeps working on the server layer adding metadata and/or validation logic which will also be available to the client application.

In the next post I’ll cover the metadata specification for our entities and that should be enough for our server-side layer, so far.

The following picture describes how an application can be layered into multiple Modules, all hosted within regions of a Shell. These modules can communicate with each other through well defined messages and contracts defined in the module Infrastructure layer. Furthermore, they retrieve and manipulate data objects through WCF Services that are suited for DDD (called WCF RIA Services). These data objects are often called entities and can represent your Domain Model and are persisted in a data store using Data Access Objects that abstract both the data store and the data access technology you’re using. WCF RIA Services provides ways for you to manipulate your entities in the client similarly as you would do in the server when it comes to querying, changing data and submitting changes.

Such application often relies on server-side infrastructure for authentication and authorization, logging and error management. At the client-side they rely on frameworks that help reduce, harmonize and reuse code in module development both at the presentation logic and at the presentation views. Some layers may have components that depend on components from other layers. In such cases, we reduce these dependencies with IoC containers or similar frameworks like MEF.

Developing in an N-layered architecture can be troublesome when you want to reuse code that has to be specified both at server-side and at client-side when it comes to validation or other business logic. WCF RIA Services relies on metadata that describes entities how entities are defined, validated and how they behave with each other. Although this technique is very effective, there are related problems that aren’t noticed until you actually hit them and I’ll try to identify and address some of them.

Notice the mapping layer between the Data entities and the Domain entities. This layer is “optional” and can be useful when you don’t want to expose your data entities as your domain model. This helps achieve persistence ignorance and also allows you to create simple and lightweight classes to transport data. For simplicity, I’m not going to use this layer in the upcoming posts, so my data entities will be my domain entities.

In the following posts I’ll be building an app that respects these layers and will evolve over time. I’ll also build a simple framework aimed for MVVM development to show how effective this pattern can be.

Never soon enough, but see you soon.

First we have PRISM (Composite Application Guidance for WPF and Silverlight). PRISM is composed of a guidance and a set of libraries that are designed to help you more easily build modular WPF and Silverlight apps. It also has built-in components that let you take advantage of some known patterns like MVVM, Event Aggregator and Dependency Injection. There are others but I’ll focus on these three because I find them to be the most useful.

PRISM applies to client development. I think the best feature PRISM provides is the ability to specify your application modules (XAPs in Silverlight) as a catalog and load them on demand. We’ll explore this in detail in other parts of this series when we create a module catalog to be used within the application.

Dependency injection (a specific usage of the Inversion of Control concept) is a prime technique for building loosely coupled applications because it provides ways to handle dependencies between objects. It helps you build testable code because you can easily switch concrete implementations which your objects depend on. PRISM is built using this design principle and it uses the Unity container, which implements the DI technique. PRISM also lets you use other DI containers but I’ll focus on Unity since I haven’t enough experience with others.

This pattern can be applied in both client and server development.

I didn’t find a nice and simple figure about Dependency Injection so I’ll link to this post where I’ve used this technique in a WCF Service (OrderService) which used an IOrderRepository implemented by the OrderRepository class which had dependencies being injected in its constructor.

The MVVM pattern is becoming the alpha and the omega when building WPF and Silverlight apps. It helps you separate concerns when designing your presentation layer and if it is well thought you can create a great set of reusable code for your application and even reuse it for other applications.

With MVVM you basically think of your view as a set of classes and properties and not as a set of UI controls. This allows you to easily switch your UI while keeping the same logic that it is bound to, and at the same time enables testability. Plus it allows you to reuse a set of UI logic in lots of views with less effort. This pattern is applied to client development.

The Event Aggregator pattern allows you to build your app with an Event Driven Architecture where components communicate with each other in a decoupled manner. It provides a way to publish and subscribe to events without knowing who is subscribing or who is publishing. The only thing you need to know is the event you are publishing or subscribing and how to react to that event. Usually modules do not depend on each other and using events as contracts to communicate between them is a good approach. This pattern applies to client development.

Next we’ll focus on server development.

Client-server communication in Silverlight has been enforced and recommended to use web services. Since we are building LOB applications it makes sense to use services that are good to deal with data. WCF services sure are good but are they ideal? What’s the cost of maintaining a complete service layer that lets us expose CRUD operations on our data and also provides us the ability to do other queries (like get products by productType), or other business operations? How many times have we done this? And how many times have we done this for different applications? How about validation of the data on the server and client side? How about proxy generation? How about the amount of data sent to the wire just to change a DateTime value on the database?

We all know Visual Studio’s generated code is ugly as hell and maintaining client-side complete service agents can be troublesome, because you usually need to keep it synchronized with your service contract. In Silverlight it is slightly more complicated to share an assembly with service and data contracts than WPF, because of type incompatibilities. Also we usually like our client-side data contracts to implement INotifyPropertyChanged and use ObservableCollections so we take advantage of data binding but at the server we really do not care about this.

WCF RIA Services aims to solve all these problems and many others.. I’ll skip the “all the things RIA Services can do part”, and point you to the right place if you still don’t know. The most important features we’ll explore are query composition, data validation, change tracking, unit of work, among others.

I’ve been using RIA Services for the last 7 months and one thing I find very useful is that the way you communicate either with the server and with your model (at the client side) is through a very well defined API which makes it easy to create very generic code that can be used to create reusable viewmodels. This is especially useful when you have multiple persons working in the same project and you want to ensure that everyone will code the same way (I will definitely explore this in later posts).

WCF RIA Services current release is the RC2, it has a go live license, so we’re good to go.

This doesn’t mean you shouldn’t use WCF as well. There are cases where WCF RIA Services isn’t well suited to work for. For example, file uploading or downloading. In this situation it’s preferable that you create a WCF Service or an HttpHandler to deal with this particular case.

For our data layer the best options nowadays are still NHibernate (using Linq to NHibernate) or Entity Framework. Nevertheless, we should encapsulate our data access through repository objects and do not use our data access technology directly in our services. I’ve got a very simple post that talks exactly about this. In this case, we can use any or both. RIA Services generates code on the client based on reflection and other metadata that is applied in our server side entities. If you use Entity Framework with RIA Services it already has a specific metadata provider that is able to understand relationships between entities and generate them correctly in the client. If you wish to use NHibernate you will have to specify additional metadata in your entities. For simplicity I’ll use Entity Framework. There are other resources on the web that explains how to use NHibernate.

Last but not least, I’d like to talk about MEF. MEF stands for Managed Extensibility Framework, has been shipped with .NET 4 (SL4 also) and is designed to help us compose our apps in a decoupled way much easier than using an IoC container for dependency injection. You simply annotate your classes with Import/Export attributes and MEF will resolve dependencies between objects for you. Of course there’s more we can do. You can provide metadata when exporting an object and import only objects that follow some criteria. MEF can be used to download XAP’s when an Import must be satisfied and the exported object is in another XAP, which helps building modular apps. It is said that the new Prism version will use MEF for its modularity features, which makes it even more interesting.

In the next post I will start with a simple business scenario and follow a top-down approach by designing an architecture built upon these technologies. I haven’t had much time lately but I’m trying to catch up so see you soon!

A lot of people think of Silverlight as just another Adobe Flash rival because of the RIA aspects both technologies offer and the strong multimedia support that Silverlight has. While this is true, we can get much more from Silverlight if we think of it as good technology for the software industry in Information Technologies. IT projects are all about manipulation, visualization and understanding data.

Silverlight, which is a subset of WPF (excellent to deal with data through data binding) and still a .NET application, when combined with today’s most popular patterns and some key technologies for software engineering, can be a very productive, straight-forward, reliable and successful technology to build this kind of applications, and at the same time, provide great UX.

In this series of posts I will try to cover key aspects when you are architecting an application that can start small, are meant to last for years and over time evolve into a bigger application due to new requirements and be developed by multiple teams without resulting in a big mess of code that no one ever wants to touch.

Such applications often are built using the following principles:

• Separation of Concerns
  • The most important principle. Ability to divide and conquer by creating layers in your application that are meant to deal with a specific problem, task or functionality, thus reducing complexity. The rest of the principles are all based on this one.
• Loosely coupling
  • Ability to create multiple components that can work together but do not depend on each other.
• Flexibility
  • Ability to respond to future changes, either by completely switching the underlying technology or business needs.
• Extensibility
  • Ability to create new functionality by extending or reusing existing one.
• Modularity
  • Ability to create well defined (cohesion) independent business areas in your application that can be evolved separately, integrate with each other and even be deployed separately.
• Testability
  • Ability to avoid/prevent unexpected bugs by changes or new functionality you make, by testing your application’s logic, behavior or dependencies.
• Maintainable
  • Ability to quickly find the code you need to change, understand it and change it, even if the one who wrote it in the first place is not around anymore (happens frequently).
• Reutilization
  • Ability to reduce code by creating components that will be reused by other components that require a specific functionality.
• UI Independence
  • Ability to switch your presentation controls without breaking neither your presentation logic nor your application logic.
• Localization
  • Ability to target multiple languages, thus increasing your range of customers.

I’m thinking in starting with an overall architecture, choose the right technologies, build a small application on top of it and then keep composing it. I’ll start with .NET 3.5 and later on move to .NET 4.

See you soon!

I’ve been developing web app’s since I’ve started my career but I had the chance to develop some mobile app’s as well, and I gotta tell you, for me developing for mobile devices is very challenging and much more interesting than web app’s. 

I really enjoy .NET Compact Framework but when you want to do some cool UX stuff it’s a pain in the butt.

Last couple of years I’ve been working mostly with Silverlight/WPF and I’ve been waiting for a Silverlight release for Windows Mobile 7 (now called Windows Phone 7 series) for a long time.

I can’t wait until I start developing for mobile devices with Silverlight, and now being able to target Symbian devices as well it feels like the cherry on top of the cake.

On a side note, I’ll be attending Microsoft’s technology event in Portugal, Techdays 2010 on 20th,21st,22nd of April, and I’ll be most interested on Architecture, Web/UX, Mobility and Cloud sessions. I hope everyone has a chance to participate!

I’ve just created a project at google.code to host the source-code of examples in this blog.

Check it out at https://code.google.com/p/mfelicio-wordpress/

I use Tortoise to access the SVN repository.

As I keep posting I will be updating the sources at google.code.

If anyone has trouble accessing it I will be willing to help.

We can achieve our goal as simple as this:

public sealed class IoCInstanceProvider : IInstanceProvider
{
    private readonly Type serviceType;

    public IoCInstanceProvider(Type serviceType)
    {
        this.serviceType = serviceType;
    }

    public object GetInstance(InstanceContext instanceContext)
    {
        return GetInstance(instanceContext, null);
    }
    public object GetInstance(InstanceContext instanceContext, Message message)
    {
        return IoC.Current.Container.Resolve(this.serviceType);
    }
    public void ReleaseInstance(System.ServiceModel.InstanceContext instanceContext, object instance)
    {
        if (instance is IDisposable)
            (instance as IDisposable).Dispose();
    }
}

The IoC class is just a singleton I use that exposes an Inversion of Control container like Unity.

The IoCInstanceProvider can be used in an existing service by applying an IServiceBehavior to that service through its ServiceHost. The following class shows how we can do this:

public sealed class IoCServiceHostBehavior : IServiceBehavior
{
    public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {
        foreach (var channelDispatcherBase in serviceHostBase.ChannelDispatchers)
        {
            var channelDispatcher = channelDispatcherBase as ChannelDispatcher;
            if (channelDispatcher != null)
            {
                foreach (var endpointDispatcher in channelDispatcher.Endpoints)
                {
                    endpointDispatcher.DispatchRuntime
                                      .InstanceProvider = new IoCInstanceProvider(serviceDescription.ServiceType);
                }
            }
        }
    }
    public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)
    {

    }
    public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
    {

    }
}

The ApplyDispatchBehavior method ensures that for every endpoint provided by the service host for a given serviceDescription, the InstanceProvider used to create the service by the wcf runtime is our own IoCInstanceProvider.

Now we create our own ServiceHost class and make sure we add this behavior before the service host gets opened (if we don’t, the behavior will not get applied).

public class IoCServiceHost : ServiceHost
{
    public IoCServiceHost(Type svcType, params Uri[] baseAddresses)
        : base(svcType, baseAddresses) { }

    public IoCServiceHost(object singletonInstance, params Uri[] baseAddresses)
        : base(singletonInstance, baseAddresses) { }

    protected override void OnOpening()
    {
        this.Description.Behaviors.Add(new IoCServiceHostBehavior());
        base.OnOpening();
    }
}

In my previous post, I used an example where I had a wcf service that used the Repository pattern with EntityFramework to query data instead of using the ObjectContext directly. I kept a parameterless constructor in the service and commented the constructor that should be used if I could have my service be resolved by the IoC container. Following the guidance of this post we can finally use that constructor and throw away the parameterless one.

[DbContextBehavior]
public class OrderService : IOrderService
{
    private readonly IOrderRepository orderRepository;
    //not used anymore
    //public OrderService()
    //{
    //    this.orderRepository = IoC.Current.Container.Resolve<IOrderRepository>();
    //}
    public OrderService(IOrderRepository repository)
    {
        this.orderRepository = repository;
    }
    //..
}

If we want to host our service in a console application we can simply do this:

var host = new IoCServiceHost(typeof(OrderService));
host.Open();
//wait for calls...
host.Close();

If we’re hosting it in an asp.net environment and have an .svc file we need to edit the asp markup file and specify a ServiceHostFactory class in the Factory attribute. The following code shows how we can write a ServiceHostFactory class uses our IoCServiceHost:

public class IoCServiceHostFactory : ServiceHostFactory
{
    protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
    {
        return new IoCServiceHost(serviceType, baseAddresses);
    }
}

I’ve used this approach in several projects (professional and academic) and I’m very happy with the results. Being able to have my services be resolved with an IoC container helps me mantain/evolve my services in many different ways and always keep my code as clean and decoupled as possible. I hope you can take benefits from this technique too.