Validations in M-V-VM demo SL4 application

This post describes the validations in my SL4 demo application using MVVM pattern in more detail.

The prerequisites:

• View talks (binds, calls) to ViewModel
• ViewModel exposes Model (any object graph) using a property (in Caliburn there is a property called Subject) => View can bind to the Model + any his property
• The effort for developing Model and all the validation aspects should be minimalized
• We need the validation ;o)

I differentiate the following validations:

• UI input fields validation – e.g. a validation of an input in a textbox
• A model validation – this validates the viewmodel and model in context of an action, e.g. validate Person in context of “UnregisterUser”  task.

There are 2 tasks related with the validation:

• validate the object
• inform the user about the validation failures

Silverlight 4 supports these tasks via two interfaces: IDataErrorInfo, INotifyDataErrorInfo. INotifyDataErrorInfo is used for the asynchronous validation purposes but this can be achieved also by IDataErrorInfo together with INotificatonPropertyChanged (which is my case).

The solution

Task 1 – enable UI validation infrastructure

In order to enable the UI validation on both Model and ViewModel it’s necessary them to implement IDataErrorInfo. Just to remind, IDataErrorInfo interface looks like:

How is this interface used:

Let’s have a view which is bound to the property of the model (The model is exposed via property Subject on the viewmodel). When the validation should be evaluated, SL casts the object whose property should be validated (in this case a model) to IDataErrorInfo and asks its indexer this[property] for the errors.

The model has no glue of any its validation rules. It’s not his concern and it doesn’t know the case in which it’s used. So in order to get the validation errors the model forwards this task to it’s validation root – which is the viewmodel – and pass him the path from the validation root to that property. The same applies for the viewmodel itself . All of these forwarding, etc. is the boilepart infrastructure code which is necessary to write for each viewmodels and models. .

In order to avoid coding the same boilepart infrastructure code, I created two base classes: ValidatableModelBase  and ValidatableViewModelBase.

Task 2 – create the validators

I used FluentValidator as the base validation framework and I separated that validation concern to the validator classes. So there are [Person]ViewModelValidator, [Person]Validator. For more info about FluentValidation check this

ViewModel is the master/director/manager in the MVVM pattern. His responsibility is drive the view. So the ViewModelValidator is the master of the validation for the view model. Because the validation and notifying the UI are very coupled tasks/concerns, I created a base class for the viewmodel validation and notification purposes and it’s called ViewModelValidatorBase.

Just to make it clear:

ModelValidator: validates the model. Important: they can be shared between client and server!

ViewModelValidator<TViewModel>:

extends ModelValidator concerns with UI fields validations and failure notifications.

Its concerns:

• defines which properties will be enabled for the standard UI validation
  
• validates and notifies UI in case of any validation failures
  

So then the concrete validatos can look like following:

So after satisfying the infrastructure needs and defining the validation logic + enabling what UI validations will be supported by the ViewModel using respective [xxx]ViewModelValidator we start to use it.

Using constructor injection the view model gets the dependency to its validator.

When the model/subject is set then the UI validation definition is used and the model is enabled for the UI input validations.

This will set two properties:

• the view model as the validation root
• path how it’s possible to navigate to that property (e.g. Subject.HomeAddress) from the validation root – viewmodel

So after that the bindings to properties (e.g. Street, Zip, etc.) on the property Subject.HomeAddress  are able to get the validation errors.

Validation in the action

An action in the view model can ask viewmodel’s validator to validate the viewmodel instance in context of the action and then process the validation result.

Processing includes notifying the view about the validation failures and using this result in the action’s business logic.

This solutions gives me the following goals:

• I can share/reuse the validation rules for the models between client and server
• The standard validation mechanism in SL4 is supported (unfortunately, binding and validation in SL is completely different than in WPF and unfortunately written with Close/Close principal – so there are no ways to extend in any custom way in SL)
• I can use full templating and property paths to the data I want to bind to the views
• Client models are not so much ‘dirty’ from the infrastructure code, it’s necessary only to derive from the base class.

What so you think? Is it correct design? What could be made better. The source code can be found here

Porting a WPF App with MVVM Design Pattern to Silverlight 4 using Caliburn, FluentValidation

There is a demo application from Josh Smith showing usage of M-V-VM pattern in WPF. It’s taken as WPF MVVM foundation and it was published in MSDN magazine here: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx [DemoApp1]

There is another blog entry describing how to migrate it into Silverlight 4 here: http://edventuro.us/2010/03/porting-a-wpf-app-with-the-model-view-viewmodel-design-pattern-to-silverlight-4/ [DemoApp2]

Because of our current project I work on a proof-of-concept for a smart client based on  SL4, I used the demo application as a basement and I rewrote it using Caliburn (as an application framework) and FluentValidation (for hte client side validation).

The main differences against the ported demo application [DemoApp2] are:

View resolution/instantiation based on the view-model class types. The idea behind the scene is that the viewmodels are prohibited to talk to any UI specific part and views ( View -> ViewModel/View, ViewModel -> View). When it’s necessary to open another view from the view model, we “activate” the viewmodel or return a subroutine result (a similar concept as with ASP.NET MVC and their ActionResult).

Then it’s necessary to bind the active viewmodel to display a content control in UI.

In this case Caliburn tries to locate some view (based on a convention) to display/present the active viewmodel. You can find more info about it on http://caliburn.codeplex.com/documentation.

The next IMHO improvement is the messaging mechanism in Caliburn. In other words, the messaging is the mechanism how to call any method on viewmodel from the view or how to send a message from the view to the viewmodel. This mechanism replaces usage of commands together with any interactivity definitions (attaching to the event and reacting). More info can be found here:  http://caliburn.codeplex.com/documentation. I used it for displaying and handling the list of the menu links.

The viewmodel instatiates the list of the actions.

We bind then the model of the messages to the view like following

The last but not least part is the  validation on the client side. A little bit background note: There are 3 different types of the validations:

a) UI validation (in SL done via IDataErrorInfo internface)

b) ViewModel input validation/handling, navigating the user to input the correct data

c) model validation

In Josh’s demo application the viewmodel copies the model’s properties and wraps them +  the validation logic spreads among viewmodel and models. Yes, models contains the data, notifications and plus the validation (which could contain the multilanguage support). I think, this is breaking the separation of concerns and that’s the reason I usedFluentValidation to do the validation => I separated the validation concern into the special class(es) with the suffix Validator.

It looks like Silverlights was designed with Close/Close principle (many classes are sealed, internal methods, internal constructors) there are very few parts which we can extend (binding, validation, validation errors, etc. – all are very tightly coupled from the extension point of the view).

So we need to follow stander IDataErrorInfo mechanism to UI support validation. So every model class will need to implement IDataErrorInfo. I had to separate Silverlight infrastructure code into a base class called ValidatableModelBase  and my models derive from it. That’s the way where model is not disturbed very much by IDataErrorInfo specifics.

ViewModel exposes a model, called subject.  ViewModelValidator<TViewModel> then enables ViewModel properties and their child to be validatable (fullfulling the UI requirements).

[class model]

It’s a concern of the viewmodel validator to decide what (what properties)  and when will be validated.

Then ViewModel or any model class is able to validate its properties and return the error message (supporting the multilanguage).

 

ViewModel (as a validation root) validate method:

 

The main Validation goals I wanted to fullfill:

a) do not drive the validation by throwing the exceptions

b) viewmodels shouldn’t copy the model properties and wrap them. It increases the amount of the code and complexity in more advanced scenarios

c) models should only hold the data and inform about their changes (INotifyPropertyChanged). Unfortunatelly, they need also derive from the base class which provides the infrastructure code (IDataErrorInfo).

The validation is bigger part and I’d like to provide an additional blog entry only about the validation.

What blog entries will follow:

• connecting the server side with Agatha [preffered] or RRSL Lite in order to communicate with the server + generating the models (entities) for the view model
• unit testing of the client side
• finalizing the server side
• enhancing the client/server with tracing and logging
• client side and server side validation

You can download the code here: MvvmSilverlightDemoApp.zip (after downloading remove the extension txt)

 

Caliburn(WPF, Silverlight/WP7): Extending the default convetion model to support the convention on more attributes

I like “convention over configuration/over-specification” approach very much. Caliburn is a briliant framework for building UI layer for Silverlight/WPF/WP7 apps with IoC,DI, extensibility, configurability, etc. using convetions.

We work on a proof of concept how we could (I will use it on my new project) use it. I publish the complete project later. But what I want to decribe here is that Caliburn supports the convetion style with the default property binding and how it would be good to extend it.

Let’s say I have a view model with the property Item which has the properties Title and Description.
So the final result I’d like to achieve is:

 

So XAML for that above result with the default element convention is:

 

Hm, I’m mixing convention and explicit style of definition. That’s not very good, I think. If I argue that Convetions are perfect I would like to use them in more than default situations.

Caliburn supports extensible model of conventions in this way (I write it in BDD style, it’s just for inspiration):

As a developer
I want to extend the default property convetions for new controls so
That I'll be able to use that convetion for new controls.

A possible solution could be:

 as a developer
 I want to extend the ANY! property convetions for ANY! controls
 so that I'll be able to use that convetions in UI layer.

So then I would write in XAML the following:

To support this I had to extend Caliburn convetion model:

1. IElementConvention has new property
   

   This will enable to specify both: bindable property(target – where the data will be bound) and identification property (source – specifies what property contains the source data property name)

2. DefaultElementConvetion which implements IElementConvetion
3. DefaultConvetionManager which enables to specify both convention-required properties. Example for Textblock control:

   
   The fist definition code adds the default convention with “Name” as the identification property and “Text” as  the bindable property.
   The second definition code adds the additional convention for Tooltip where bindable and identification properties are same.

4. method TryCreateApplication - a place where the convetion is tranformed into so called applicable binding and where the value in Identification property is taken as a source for determining the path to bind in the XAML binding.

   

I’m going to post it to the author of Caliburn if that would be a feature suitable for the framework. I think it culd be because it would enable to extend the default element bindings not only for Name properties but for any such property.

 

That’s all for now ;o)

NDepend for analyzing the design quality of code

I came back to a project I worked on 5 years ago. It was quite “interesting” to see the code after such long pause. We had to extend the application with few new features but I wanted to make sure the code is upgraded to higher code quality level. But it’s necessary to have some facts which will prove the higher code quality.

I decided to use NDepend for it. NDepend does the static code analyze. FXCop does the similar thing BUT! NDepend creates its own DB of the metrics/data gathered from the analyzed source code. You can query the data using CQL (code query language) or you can check few charts made by NDepend. CQL is also used to build the rules which could be evaluated to ensure good degree of code quality. It’s possible to use it using while continues integration process.

But there is one essential requirement! You need to be familiar with all the code metrics and CQL. You can find the detailed info about the metrics here. It took me a while to understand (I say “to feel”) them almost all.

GRAPHS

From my point of the view the graphs are the first parts which gets the user’s focus. One of the most usefull graphs is the Abstractness vs. Instability graph (AvI graph). If you want to understand the metrics more in deep, read this.

There is another blog post here which displays the “evolution” of the understanding of the code/metrics for AvI graph. Igloocoder shows what are the most important changes to his code in order to increase the code quality. He drives you through the changes and he finished with not very successful results because the refactored assembly didn’t end-up in the “green area”.

Just to clarify the goals of the graph:

1. The goal is to end-up in the green area.
2. split the assembly roles:
   • the abstract stable assembly – the assembly with high abstraction level and with very stable contract, used by many other assemblies
   • the concrete instable assembly – the assembly with very much of the concrete implementations and which are the area of the change with smaller direct usability => that’s the reason why it’s called instable = more probable to change

Igloo’s code end-up with the refactored code located in 1 assembly and the result is:

Unfortunately he didn’t do the final step. AvI graph is about the assemblies. So I tried to finish his analyze.
If we move the interfaces into a special so-called contract assembly then we get the following solution:

NDepend will generate for us the next graph:

If we remove the code analyze of the tests and exclude ALL system assemblies from the code analyze (I call it “we clean up the noisy assemblies) then we end-up with the ideal situation:

So Igloocoder was very close to the final solution.

If you want to know how the graphs are created it’s necessary to use and understand CQL. You can query and analyze the code metrics on different levels, e.g. assemblies, namespaces, types, types.

Here is the query which I used to analyze the instability metrics for the interfaces. The result grid displays as many collumns as WHERE clauses you write into CQL query.

As you can see NDepend measures Ce (aka efferent coupling) including references to the types from system assemblies, e.g. mscorlib. From my point of the view I’d like to clean up such MUST references and don’t include them into the measurements. It’s possible to do it when you manually change the configuration NDepend created for you. Here it is:

After that the AvI graph looks like the following:

That’s all for now. We are going to include NDepend measurements into our CI process just to have a view over our code.

Entity Framework: logging

I use EF4 CTP5 and I’d like to log ANY!!! SQL commands sent to the DB. You can use the method ToTraceString() to display the SQL commands of any ObjectQuery, but … you are not able to see the queries generated i.e. while saving changes OR lazy loading. You need to use i.e. EFProfiler to log it. EFProfiler is very cool tool but … I need to log it by my application.

So I found out the Tracing and Caching implementation by Jaroslaw Kowalski here which extends EF with tracing/logging and caching capabilities. The main disadvantages I found out are:
a) you need to you both! features otherwise logging/tracing will not work. I wanted to use only logging! After doing so I started to get strange exception (or I had to do something wrong). After enabling also tracing, it started to work. Shame because I needed to use ONLY tracing.
b) your Context classes HAS to be derived from his special classes.

Honestly, I don’t use this solution. It’s too much work.

MS guys, I’m sorry but I must say: IT’S BIG SHAME EF WAS NOT DEVELOPED IN EASY EXTENSIBLE MANNER with i.e. ServiceLocator, interceptors, etc. in place.

As far as I know, and correct me if I’m wrong, adding logging capabilities fits to AOP interceptors.

I.e. EFProfiler has quite hardly injects itself into creating new DB connection logic and then it has a capability to log everything. Their solution is more transparent than a by Mr. Kowalski.

My solution
I used the ideas from NHProfiler and I generalized it little bit. I made base AOP filter called IAopFilter.

public interface IAopFilter

    {

        void CommandDurationAndRowCount(Guid connectionId, long milliseconds, int? rowCount);

        void ConnectionDisposed(Guid connectionId);

        void ConnectionStarted(Guid connectionId);

        void DtcTransactionCompleted(Guid connectionId, TransactionStatus status);

        void DtcTransactionEnlisted(Guid connectionId, IsolationLevel isolationLevel);

        void StatementError(Guid connectionId, Exception exception);

        void StatementExecuted(Guid connectionId, Guid statementId, string statement);

        void StatementRowCount(Guid connectionId, Guid statementId, int rowCount);

        void TransactionBegan(Guid connectionId, System.Data.IsolationLevel isolationLevel);

        void TransactionCommit(Guid connectionId);

        void TransactionDisposed(Guid connectionId);

        void TransactionRolledBack(Guid connectionId);

    }

Due to the short of the time, I made only 1 its implementation and it was using Log4Net capabilities. Then I had to create AOP capable DbProviderFactory class called DbProviderFactoryEx which uses IAopFilters. In addition I had to create whole family of the classes following abstract factory pattern implemented in DbProviderFactory.

The main class is called EntityFrameworkExtender. This class wires-up AOP capabilities into EF. You just need to call:
EntityFrameworkExtender.Initialize();

The class by default uses Log4NetFilter as only the one filter but you can freely configure it.

EntityFrameworkExtender.Filters = () => new[] {new Log4NetFilter(“MyClass”)};

            EntityFrameworkExtender.Initialize();

Using it you are able transparently trace/log every SQL command sent from EF to DB.

I think, we, EF users would profit very much IF the EF team would develope the framework on enterprise level – easily extensible, configurable and if we could get also the unit tests! together with the framework.

[UPDATED!]
I bundled the whole source code into 1 project. The whole source code can be found here - save it as a file to the local disk  and delete .doc extension. It’s  normal zip file.
To use it you will need: log4net 1.2.10.0, EF4 CTP5, .NET 4.0

Entity Framework: Problem/Solution of default connection closing !

I use EF CTP5 on my last project together with NCommon and its UnitOfWork, Repositories, IoC and DI abstracted by MS P&P team and StructureMap as the concrete implemetation of IoC and DI.

Problem :
Let’s have the following example (I took the example from the NCommon unit tests and extend it to do the same Linq query twice):

using (var scope = new UnitOfWorkScope())

{

    var repository = new EFRepository<User>();

 

    User user;

    user = repository.Where(u => u.ComsiID == "login").FirstOrDefault();

    user = repository.Where(u => u.ComsiID == "login").FirstOrDefault();

 

}

 

Just for the completion: creating new UnitOfWorkScope starts the DB transaction. In the above example, using UnitOfWork we create and start the transaction. Then we create new EFRepository instance which creates the ObjectContext. ObjectContext uses the connection identified by the same name AppDb and handles the connection on its own. Then we query the DB. EF opens the connection (this implies that the connection is enlisted into the current running transaction), reads the data and then close the connection. Fine! But then next (in this demo case) same query does the same: opens the connection. Because we run inside the transaction, so the connection is also enlisted into the transaction. And because there was already enlisted connection the transaction mechanism propagates it into DTS.

The result of the above code is that it works and sometimes not! The exception is following:
System.Data.EntityException: The underlying provider failed on Open.
---> System.InvalidOperationException: The connection object can not be enlisted in transaction scope.


THE PROBLEM IS IN ENTITY FRAMEWORK!!!!! and the result of the test depends on the underlying DB. If you use SQLExpress edition (as is used by default in NCommon unit tests), everything works fine! SQLExpress can not elevate the transaction to MS DTC. But if you change the connection to the real SQL server you starts to have the problems.

The problem is that in case you don’t send the concrete connection instance to EF, EF handles the connection status on his own => closes as soon as possible. I understand it but in case of Transaciton is fails! It would be good to have there a switch to configure that behavior. Anyway, the reality is different so how to fix it.

The solution is to manage the connection by your own and while creating the ObjectContext pass already created and open connection. You can find many examples about it on the internet.

Hm, fine but … not so nice. You need manually on all places where ObjectContext, or your class derived from ObjectContext, is used to manage the connection

With NCommon and it’s configuration capabilities you can do the following:

NCommon.Configure.Using(adapter)

    .ConfigureData<EFConfiguration>(config => config.WithObjectContext(

        () =>

        {

            AppDb db = new AppDb();

            if (Transaction.Current != null)

            {

                db.Connection.Open();

            }

            return db;

        }))

.ConfigureUnitOfWork<DefaultScopeUnitOfWorkConfiguration>();

 

 

So you don’t need to do open the connection over and over and on different places. Just configure NCommon on one place and use it. That’s the power of the centralized factory code-enabled configurations. In this case, thanks to StructureMap and NCommon!

---

Here is my full unit test class (using MS Tests):

[TestClass]

    public class SimpleTests

    {

        public IServiceLocator MyServiceLocator;

 

        [TestInitialize]

        public void Setup()

        {

            var _state = new FakeState();

            var _unitOfWorkFactory = new EFUnitOfWorkFactory();

            var _connectionString = ConfigurationManager.ConnectionStrings["AppDb"].ConnectionString;

            _unitOfWorkFactory.RegisterObjectContextProvider(

                () =>

                        {

                            var ctx = new AppDb(_connectionString);

                            if (Transaction.Current != null)

                            {

                                ctx.Connection.Open();

                            }

                            return ctx;

                        });

            var _locator = MockRepository.GenerateStub<IServiceLocator>();

            _locator.Stub(x => x.GetInstance<IUnitOfWorkFactory>()).Return(_unitOfWorkFactory);

            _locator.Stub(x => x.GetInstance<IState>()).Do(new Func<IState>(() => _state));

            ServiceLocator.SetLocatorProvider(() => _locator);

        }

 

        [TestCleanup]

        public void Cleanup()

        {

        }

 

        [TestMethod]

        public void Can_perform_simple_query()

        {

                using (var scope = new UnitOfWorkScope())

                {

                    var repository = new EFRepository<User>();

 

                    User user;

                    user = repository.Where(u => u.ComsiID == "a").FirstOrDefault();

                    user = repository.Where(u => u.ComsiID == "a").FirstOrDefault();

 

                }

        }

I must again say, NCommon and StructureMap rocks!

Happy coding…

NCommon: read-only operations = Unit Of Work without DB transaction

Using NCommon I found one feature which can be an issue in some cases.

Repository can ONLY be used when you started an unit of work around it. Example:

using (var scope = new UnitOfWorkScope())

            {

                var savedCustomer = new EFRepository<Customer>()

                    .First(x => x.CustomerID == customer.CustomerID);

                scope.Commit();

            }

When new unit of work is created then it automatically starts the database transaction in the mode ReadCommited. Issue is that in case I need ONLY to read a data then I think, it’s too heavy. In other words why to pay the performance costs of creating a transaction when I want only to read the data from DB. In the default NCommon implementation this wouldn’t work:

var savedCustomer = new EFRepository<Customer>()

                    .First(x => x.CustomerID == customer.CustomerID);

I think it would be good avoid creating the DB transactions in case of read-only queries. It’s quite generic/DB-provider independed functionality so it fits into the base NCommon Repository classes. Unfortunatelly, I didnt want to change the base classes because in case new NCommon is releases and I changed the core functionality then I need to be in sync with latest NCommon verions. So I created my derived implementation for Entiry Framework v4. If there is no unit of the work created I create a single call unit of work without any transaction. Again, I think the change should be in the base NCommon classes but I wanted to stay compactible with the base classes as much as possible so I changed only the concrete Repository implementation for Entity Framework.

So using my changes the previous example works!

What do u think?

The changed NCommon for EFv4 can be found here

EFv4 with Repository and UnitOfWork pattern, IoC, DI

Entity Framework itself implements unit of work pattern in form of the ObjectContext class. That’s fine but it has the following main disadvantages:
a) if you will use it from your business layer then you will be very tightly connected to the concrete DB layer implementation (in this case Entity Framework)
b) it will be much harder or impossible to do TDD.

It’s good practice to wrap the data access logic using Repository pattern. In other words it’s good to use the Repository pattern in order to abstract out/decouple the business layer from the data access layer. Fine, there is one Repository patter definition but many implementers and you can implement it also by your own. The basic idea is the same but many slightly different implementations.

When you work on different projects developed by the different people it’s good to establish enterprise-wide implementation of any common patterns/areas. Additionaly, it would be better if ti would be world-wide known implementation. So that’s NCommon which you can find on ncommon.codeplex.com.

NCommon provides, we could say, abstraction of the common programming areas like Repository, UnitOfWork, Guards, States, etc. In this entry I’ll focus on Repository.

NCommon provides the abstract Repository implementation – independent from any specific/concrete DB access implementation PLUS it contains implementations for Entity Framework, NHibernate, Db4O, etc. All specific implementations are located in its own projects. The advantage is that you can use out of the box implementation of your favorite implementation.

In addition, the base abstract Repository class offers LINQ provider on Class Level, not property level. Honestly, I like it ;o). Here is a sample:

using (var scope = new UnitOfWorkScope())

{

    var savedCustomer = new EFRepository<Customer>()

        .First(x => x.CustomerID == customer.CustomerID);

    scope.Commit();

}

 

In addition the base NCommon Repository classes are tightly connected with UnitOfWork pattern which is also abstracted into NCommon in form of UnitOfWork classes. You can get it also out of the box together with the different DB access specific implementations!

The unit of work implementation IS NOT ONLY 1 CONNECTION specific but spreads over different repositories and over different DB connections (if it’s your case). In other words, you can have i.e. a users repository implemented by NHibernate and connecting to UsersDB and OrdersRepostory implemented via EntiryFramework connecting to OrdersDB and the following example works:

In other words, one connection transaction will be elevated to the distributed transaction transparently and automatically. I like it! It seems to me really robust.

ALL is supported by standard service locators implemented by Microsoft Patterns and Practices team and with the NUnit tests!

I think, NCommon is really cool set of classes which collects the common aspects you will face while development. It’s really worth studying it! Here is a list of the links you can use:

• http://code.google.com/p/ncommon/
• http://www.codeinsanity.com/search/label/NCommon

Anyway, cool way how to check the latest library description is to look at the unit tests from GitHub.

Happy common coding !

MVCContrib extension – Localized Labels, Description

I use MVCContrib library on one of my ASP.NET MVC 2 projects. That project should have multi-language support. I use InputBuilders quite much but InputBuilders don’t support the multilanguage features for i.e. Labels, Descriptions, etc..

So I realized to extend it.

So to fully understand this blog entry you nee to be familiar with MvcContrib InputBuilders and the way how the default multi-language support is done in ASP.NET MVC.

There is quite nice article written about the localization here. There are several ways how to store the multi-language texts but I like Adam’s guide because it’s quite easy.

My MVCContrib-multi-language extension

In my project I have the source code of MVCContrib, so it was easy to extend. I demonstrate my extension on Labels.

I created 2 classes:

    1 namespace MvcContrib.UI.InputBuilder.Attributes

    2 {

    3     public class LabelAttribute : Attribute

    4     {

    5         public Type LabelResourceType { get; set; }

    6         public string LabelResourceName { get; set; }

    7 

    8         private string _label;

    9 

   10         public string Label

   11         {

   12             get

   13             {

   14                 if (!string.IsNullOrEmpty(_label))

   15                 {

   16                     return _label;

   17                 }

   18 

   19                 if (LabelResourceType != null && !string.IsNullOrEmpty(LabelResourceName))

   20                 {

   21                     PropertyInfo property = LabelResourceType.GetProperty(LabelResourceName, BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Static);

   22                     if (property != null)

   23                     {

   24                         var txt = property.GetValue(null, null) as string;

   25                         return txt;

   26                     }

   27                     return "Default:" + LabelResourceName;

   28                 }

   29 

   30                 return "";

   31             }

   32             set

   33             {

   34                 _label = value;

   35             }

   36         }

   37 

   38         public LabelAttribute()

   39         {

   40         }

   41 

   42         public LabelAttribute(string text)

   43         {

   44             Label = text;

   45         }

   46 

   47         public LabelAttribute(Type textResourceType, string textResourceName)

   48         {

   49             LabelResourceType = textResourceType;

   50             LabelResourceName = textResourceName;

   51         }

   52 

   53     }

   54 

   55     [AttributeUsage(AttributeTargets.Class)]

   56     public class LabelConventionAttribute : Attribute

   57     {

   58         public Type ResourceType { get; set; }

   59         public string Pattern { get; set; }

   60 

   61         public LabelConventionAttribute(Type resourceType, string pattern)

   62         {

   63             ResourceType = resourceType;

   64             Pattern = pattern;

   65         }

   66 

   67         public string GetLabelFor(string propertyName)

   68         {

   69             return new LabelAttribute(ResourceType, string.Format(Pattern, propertyName)).Label;

   70         }

   71     }

   72 }

Class LabelAttribute is to add the multilanguage support for the particular property. But because I’m lazy to write it on all properties of my model which is sent to the view, I create LabelConventionAttribute.

I like Convetion-over-Configuration style so using this attribute it is possible to setup the convention that the labels will be named by the convention Pattern.FormatWith(propetyName).

Next change was to change DefaultProperyConvention class to be partial. It’s due to the have my extensions in a separate class. I had to add there a method Lable

So here it’s

    1 namespace MvcContrib.UI.InputBuilder.Conventions

    2 {

    3     public partial class DefaultProperyConvention

    4     {

    5        

   17 

   18         public virtual string LabelForPropertyConvention(PropertyInfo propertyInfo)

   19         {

   20             if (propertyInfo.AttributeExists<LabelAttribute>())

   21             {

   22                 return propertyInfo.GetAttribute<LabelAttribute>().Label;

   23             }

   24             if (propertyInfo.ReflectedType.AttributeExists<LabelConventionAttribute>())

   25             {

   26                 return propertyInfo.ReflectedType.GetAttribute<LabelConventionAttribute>().GetLabelFor(propertyInfo.Name);

   27             }

   28             return propertyInfo.Name.ToSeparatedWords();

   29         }

   30     }

   31 }

   32 

And in the original DefaultPropertyConvention class I had to remove the method LabelForPropertyConvention.

That’s all. The similar steps can be done also for Description, but it’s necessary to extend PropertyViewModel class with new property.

The usage is:

    1 [DescriptionConvention(typeof(Descriptions), "Car_{0}")]

    2 [LabelConvention(typeof(Labels), "Car_{0}")]

    3 public class CarInput

    4 {

    5     [Required]

    6     [Example("BMW")]

    7     public virtual string Name { get; set; }

    8 }

Based on Adam’s guidance, I also had to create a resource file for the labels and the VS.NET created me the class Labels.

If you use MVCContrib builders then i.e. their Field.Master contains code like this: Html.Encode(Model.Label) to display the model’s label. Using the previously described extension it will be translated into the culture set in Thread.CurrentThread.CurrentUICulture.

That’s all for now …

Book Review: ASP.NET MVC 2 IN ACTION

I read MEAP version of the book ASP.NET MVC 2 in Action from Jeffrey Pallermo last month and I’d like to share my point of the view.

The book shows you how to use ASP.NET MVC 2 in Alt.Net (StuctureMap, MvcContrib, Rhino.Mocks, jQuery, NHibernate, NUnit, etc.) way – which I appreciate very much.

The book shows more how CodeCampServer.org was built connected with ASP.NET MVC 2, what is the logic, tips and tricks behind the designed solution. I must say, I like it as Headspring designed it. I just would call this book ASP.NET MVC 2 in Action on CodeCampServer project.

If you want to download and understand the code quite deeply, read this book. The quys around CodeCamperver are really cool ;o)!

If you want to know more about ASP.NET MVC 2 in general than how to use ASP.NET in Alt.NET, way then read this book: Pro ASP.NET MVC 2 Framework, Second Edition (Expert’s Voice in .NET)