iParag.com – Parag C Mehta’s .NET World

Test

Post is here : http://channel9.msdn.com/shows/Continuum/MVCPreview4/

MVC (the “model view control” pattern) isn’t new, but it is new to ASP.NET. If you’re like me, you may have been impressed by a demo, but you’ve probably thought “how does this work in the real world?” I hope to answer that question in this article.

All of the MVC demos that I have seen show how quick and easy it is to get going with ASP.NET MVC (from here on I’ll just say “MVC”). They show a CSS’d up site with a navigation section, and a main content section. And in very little code, and very little time, they show how to retrieve data from your Model (the “Controller” does this), and how to display it in your page (the “View” does this). It look so simple, but there are some design questions that need to be addressed. We’ll discuss them as we look into MVC.

MVC and Web Sites

The gist behind MVC is that a “View” is only responsible for displaying it’s data, and nothing else. This means that if you had a View named ‘UsedCars’, it is only responsible for listing out used cars. There is no code for adding, deleting or updating the data in a View itself; there is no provision for displaying anything else other than “used car data”.

So, MVC in a web application means that a View is not responsible for the navigation, header, footer or any other part of the site. With that being said, a few questions come to my mind. These are the items that this article will discuss as our ‘real world’ issues:

1. How does MVC handle dynamic sections on a website that are not part of the current “View”? – For instance, on SingingEels.com, if you’re logged in, the navigation section changes to include member’s only links. When you’re looking at an article, the “related section” on the right of the site will show you blog posts that are similar to the content you are looking at.
2. How does MVC work with validating a user input, and displaying a friendly message back to the user on a screen that he expects to see? The reason I mention this is because in MVC, an HTML form on one View will be posting to an Action (a different URL) that actually does the work. This is different than in the “Web Forms” world, where the page posts-back to itself. So if the user entered some invalid data, how do you send them back to the original View, fill out the form back to how they had it, and display the error message?

Aside from these “issues” above, we’ll see how to achieve common functionality (that we all do every day in the “Web Forms” world). These include things like creating paging functionality (I won’t explain this in the article, but it’s in the source code at the end). So, to demonstrate how to build a “full featured” MVC site that needs to solve the above issues, we’re going to build a ‘used cars’ website. There will be a list of cars for sale (that will be paginated), displaying results from a database. We’ll also have a few static pages and a “contact us” form. I’ll include the entire source code and project at the end of the article. Keep in mind, this article and demo was written for ASP.NET MVC Preview 3.

Building Our MVC Layout with MVC Master Pages

The MVC design pattern was not originally for web applications, so extending this architectural pattern to the web allows for some breathing room. This is where we will answer our first question: “how do we handle dynamic sections in our web site that isn’t part of a particular View?” Well, the answer is the same for how we handle our entire web site (the layout and styling of it) outside of any one particular View – with Master Pages!

So the first thing we are going to do with our MVC “Used Cars” website, is to create our basic layout and styles, and make a ’stub’ for our Views to live in (basically, a ContentPlaceHolder). Here’s what our site will look like:

Now, there are a few new tricks that we get with ASP.NET MVC (yes, I used the whole name here – for a purpose). The .NET team has provided a lot of powerful “helper functions” that snap right into the MVC framework. So, to make the navigation links above, I would normally have done this:

… But the problem here is that we are making links to “pages” instead of making links to “MVC Views”. This forces our file structure to be very tied to our web design, which may not be what you’re going for. Instead we’ll do this:

This allows us to define our links in terms of pointing to a ‘View’, as apposed to being tied to a specific URL. You don’t have to build your links this way, but it helps if you decide to change your route logic and you want your site to automatically update the links. Since we have our basic layout done, let’s take a look at how these pages work.

Simple ASP.NET MVC Views

For simple Views that don’t have a lot of logic around them, you don’t have to do much in your controller. So for the home page and the about us page, this is basically all of the code in my controller:

Then, in our View, we can display the data. Normally this would go in the ‘aspx’ or ‘ascx’ files, but I’m displaying the above data in the master page (since the title of the page, and the page heading could be considered part of the standard layout). Again, you can download the source code for this project at the end of the article to see for yourself.

Real-World MVC Issue : Data Validation

So, let’s get out of the boring, and talk about the other big problem that needs to be solved – form validation. When a user fills out our contact us form, we want to check for required fields and alert the user when the form is invalid. If all goes well, we’ll send the user to a “Thank You” page.

Here’s what our page will ultimately look like:

But the question remains: how do we do it? First, we build our HTML form using the helper methods:

Then, in our Controller we will do the validation:

The last piece of the puzzle is back in the contact us View. It’s where we check the TempData field to see if there are any error messages in there, and if so, we display them. There are a few things to be concerned about here with using the TempData though. Mainly, it’s important to know that behind the scenes, MVC is using the Session object to store the data between hits. Now, it is very quick to clean it up (immediately after the next request)… but if you’re using a web-farm, it’s important to remember that you’ll need a shared session pool.

In Conclusion

MVC is a beautiful new tool that will no doubt be invaluable in the future. It does require a different approach to architecting your web sites, but it can be very worth it in the end. However, it’s also important to remember that MVC is not replacing Web Forms.

I hope this article has shown that you can still achieve the functionality that you’re used to having using ASP.NET MVC. Check it out for yourself and see if you don’t grow to love it (or at least appreciate it) as I have. And of course, here’s the source code for the above project: SingingEels_MVC Used Cars Demo.zip. Again, it was written and compiled for ASP.NET MVC Preview 3.

Original Article at : http://www.singingeels.com/Articles/ASPNET_MVC_in_the_Real_World.aspx

The CLR Add-In team recently released on CodePlex a set of 49 FxCop rules to verify View and Contract assemblies. If you don’t don’t know what is View and Contract assemblies, I suggest reading this excellent CLR Inside-Out MSDN Magazine article by Jack Gudenkauf and Jesse Kaplan. It is about how to harness System.AddIn facilities.

I spent an hour implementing these rules with CQL and came to the following result. Notice that these rules can be readily adapted if you have sereval contract or view assemblies.

Rules on Contract assemblies

// <Name>Contract assemblies should not have references to non-framework assemblies</Name>
WARN IF Count > 0 IN SELECT ASSEMBLIES WHERE 
  IsUsedBy "MyContractAssembly" AND 
  // Framework assemblies are mscorlib and thos whose names begin with System.
  (!NameIs "mscorlib" AND 
   !NameLike "^System.")

// Don't reference non-framework assemblies from the contract assembly unless you can 
// be sure that the assembly can be loaded on both sides of the contract boundary.

// <Name>Contract types that represent add-ins should be marked with the AddInContractAttribute</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE
  IsInterface AND // Limiting search to interfaces only.
  !HasAttribute "OPTIONAL:System.AddIn.Pipeline.AddInContractAttribute"

// Contracts that represent add-ins and are intended to be activated should be marked 
// with the AddInContractAttribute. Contracts that only represent objects passed between 
// hosts and add-ins do not need this attribute; if all of the types in this assembly 
// fall under this category then this rule can be ignored.

// <Name>Value types defined in a contract assembly should be serializable</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE
  IsStructure AND !IsSerializable 

// Value types (structs) are only useful in the contract assembly if 
// they can be serialized across the boundary.

// <Name>Contract interfaces must implement IContract</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE 
  IsInterface AND
  !Implement "OPTIONAL:System.AddIn.Contract.IContract"

// All interfaces defined in the contract assembly must implement IContract, 
// or another interface that implements IContract. Using an interface that 
// doesn’t implement IContract can cause problems with lifetime management.

// <Name>Contract assemblies should not define types that derive from MarshalByRefObject</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE
  DeriveFrom "OPTIONAL:System.MarshalByRefObject"

// MarshalByRefObjects can cause problems with lifetime management. If this type 
// represents an object you want to marshal by reference, you should define an 
// interface implementing IContract to represent it. If it is intended to be copied 
// (and thus passed by value), then you should define a simple serializable value 
// type (struct) to represent it.

// <Name>Exception types must implement ISerializable and be marked with the Serializable attribute</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE
  DeriveFrom "OPTIONAL:System.Exception" AND
  (!Implement "OPTIONAL:System.Runtime.Serialization.ISerializable" OR
   !HasAttribute "OPTIONAL:System.SerializableAttribute")

// Exception must implement ISerializable and be marked with the SerializableAttribute 
// in order to function well across AppDomain boundaries.

// <Name>Contract assemblies should not define static types</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE IsStatic

// The state of static types is stored per AppDomain and changes to state 
// in one AppDomain are not reflected in others.

// <Name>Contract assemblies should not define reference types other than exception types</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE
  IsClass AND !DeriveFrom "OPTIONAL:System.Exception"

// The only valid reference type is an Exception type. If this type represents an 
// object you want to marshal by reference, you should define an interface implementing 
// IContract to represent it. If it is intended to be copied (and thus passed by value),
// then you should define a simple serializable value type (struct) to represent it.

// <Name>Contract assemblies should not define delegate types</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE IsDelegate 

// Delegates do no marshal well across AppDomain or Process boundaries 
// and so should not be used in contracts.

// <Name>Contract assemblies should not define exception types</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE
  DeriveFrom "OPTIONAL:System.Exception"

// If possible, you should use one of the framework defined exceptions rather 
// than defining your own. If you decide to define your own exceptions, 
// they become part of your object model and you will need to define corresponding 
// Exception types in the views and perform the conversion in your adapters.

// <Name>Non-exception types should prefer [Serializable] attribute over ISerializable</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE
  !DeriveFrom "OPTIONAL:System.Exception" AND
  Implement "OPTIONAL:System.Runtime.Serialization.ISerializable"

// Implementing ISerializable adds a significant performance overhead compared 
// to standard serialization. If possible, use the built in serialization 
// engine instead of customizing it with ISerializable.

// <Name>All interfaces used in contract assemblies should implement IContract</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE 
  IsDirectlyUsedBy "MyContractAssembly" AND
  IsInterface AND
  !Implement "OPTIONAL:System.AddIn.Contract.IContract"

// All interfaces used in the contract assembly should implement IContract, or 
// another interface that implements IContract. Using an interface that doesn’t 
// implement IContract can cause problems with lifetime management.

// <Name>Contract assemblies should not use types that derive from MarshalByRefObject</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyContractAssembly" AND
  DeriveFrom "OPTIONAL:System.MarshalByRefObject"

// MarshalByRefObjects can cause problems with lifetime management. If this
// type represents an object you want to marshal by reference, you should define
// an interface implementing IContract to represent it. If it is intended to be
// copied (and thus passed by value), then you should define a simple serializable
// value type (struct) to represent it.

// <Name>Contract assemblies should only use types that are either serializable or are interfaces implementing IContract</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE 
  IsDirectlyUsedBy "MyContractAssembly" AND
  (!IsSerializable OR
   (IsInterface AND !Implement "OPTIONAL:System.AddIn.Contract.IContract"))

// This type is neither serializable nor is it an interface implementing IContract. 
// If it represents an object you want to marshal by reference, you should define an 
// interface implementing IContract to represent it. If it is intended to be copied 
// (and thus passed by value), then you should define a simple serializable value 
// type (struct) to represent it.

// <Name>Contract assemblies should not contain any static members</Name>
WARN IF Count > 0 IN SELECT FIELDS FROM ASSEMBLIES "MyContractAssembly" WHERE IsStatic

// Static state is stored per AppDomain, and changes to state in one 
// AppDomain are not reflected in others.

// <Name>Contract assemblies should not use delegates</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyContractAssembly" AND
  IsDelegate 

// Delegates do not marshal well across AppDomain or Process boundaries, 
// and so should not be used in contracts.

// <Name>Contract assemblies should not use arbitrary types that implement ICollection<T> or ICollection</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyContractAssembly" AND
  (Implement "OPTIONAL:System.Collections.Generic.ICollection<T>" OR
   Implement "OPTIONAL:System.Collections.ICollection")

// <Name>Contract assemblies should not use a type defined simply as System.Object</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyContractAssembly" AND
  FullNameIs "System.Object"

// Using the System.Object type makes it very difficult to ensure that this
// will version well over time. If this is intended to represent an arbitrary
// contract, type you should use IContract instead.

// <Name>Contract assemblies should not use a type defined simply as System.Type</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyContractAssembly" AND
  FullNameIs "System.Type"

// Passing a System.Type across the boundary causes the assembly containing it 
// to be loaded in the other domain as well. This greatly lessens the value of 
// the isolation boundary for versioning, security, unloadability, and reliability.

// <Name>Contract assemblies should not use types from the System.Reflection namespace other than AssemblyName</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyContractAssembly" AND
  FullNameLike "System.Reflection." AND
  !NameIs "AssemblyName"

// Passing most reflection types across the boundary causes the assembly 
// containing it to be loaded in that domain as well. This greatly lessens 
// the value of the isolation boundary for versioning, security, unloadability, 
// and reliability.

// <Name>Contract assemblies should not use System.AddIn.Contract.Collections.IListContract<T></Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyContractAssembly" AND
  FullNameIs "OPTIONAL:System.AddIn.Contract.Collections.IListContract<C>"

// System.AddIn contains helper methods for using System.AddIn.Contract.IList<T> and 
// should be preffered over the version in System.AddIn.Contracts.Collections. 
// System.AddIn.Contract.Collections.IList<T> is in place largely for compatibility reasons.

// <Name>Contract assemblies should not use System.AddIn.Contract.Collections.*</Name>
WARN IF Count > 0 IN SELECT NAMESPACES WHERE
  IsDirectlyUsedBy "MyContractAssembly" AND
  NameIs "OPTIONAL:System.AddIn.Contract.Collections"

// System.AddIn.Contract.Collections.* should not be used. If you use 
// System.AddIn.Contract.Collections, you will need to write your own adapters for them.

// <Name>Contract assemblies should not declare non-public types</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyContractAssembly" WHERE !IsPublic

// The purpose of a contract assembly is to allow adapters to represent the 
// types across isolation and versioning boundaries. Making a type in this 
// assembly non-public prevents it from being used in this fashion.

Rules on View assemblies

// <Name>Activatable add-in types should be marked with the AddInBaseAttribute</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  (IsInterface OR IsAbstract) AND 
  HasAttribute "OPTIONAL:System.AddIn.Pipeline.AddInBaseAttribute"

// No type in the assembly is marked with the AddInBaseAttribute. For this assembly 
// to be used (without modification) as an AddInView, the types that represent 
// add-ins need to be marked with the AddInBaseAttribute. Even if the type will not 
// be used directly through System.AddIn today, applying this attribute now will 
// make it easier to migrate while still maintaining compatibility.

// <Name>View types should not implement IContract or an interface that implements IContract</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  Implement "OPTIONAL:System.AddIn.Contract.IContract"

// Exposing a contract directly in the view can cause a variety of problems. It makes it
// very difficult to version over time since it strongly binds the consumer of the view 
// to a particular version of the contract assembly.

// <Name>View types should not be marked serializable</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  Implement "OPTIONAL:System.Runtime.Serialization.ISerializable" OR
  HasAttribute "OPTIONAL:System.SerializableAttribute"

// Types defined in views should never have to directly cross any isolation 
// boundary, and so shouldn’t need to be serializable. You can mark these 
// serializable if you need to store them to disk but you shouldn’t do so in
// order to pass them across boundaries.

// <Name>View types should not derive from MarshalByRefObject</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  DeriveFrom "OPTIONAL:System.MarshalByRefObject"

// Types defined in views should never have to directly cross any isolation
// boundary and so shouldn’t need to be a MarshalByRefObject.

// <Name>View types should not have generic parameters</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  IsGeneric 

// Types with generic parameters are difficult to isolate, since their 
// pipeline components cannot be generated automatically.

// <Name>There should be no exception types defined in the view assembly</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  DeriveFrom "OPTIONAL:System.Exception"

// Defining your own exception makes that exception type part of your object model. 
// This means it will require a different exception type to cross the isolation 
// boundary, and adapting logic on either side to do the conversion. If at all 
// possible, you should use one of the existing framework exception types.

// <Name>View types should not be marked static</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  IsStatic 

// The state of static types is stored per AppDomain, and changes to state 
// in one AppDomain are not reflected in others. Static types in the view 
// are only OK if they provide simple helper functionality, and are stateless.

// <Name>View types should not inherit from FrameworkElement</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  DeriveFrom "OPTIONAL:System.Windows.FrameworkElement" 

// Building adapters for types that inherit from FrameworkElement is difficult, 
// since you have to hand-code them..

// <Name>View types should not inherit from Control</Name>
WARN IF Count > 0 IN SELECT TYPES FROM ASSEMBLIES "MyViewAssembly" WHERE 
  DeriveFrom "OPTIONAL:System.Windows.Forms.Control" 

// Building adapters for types that inherit from Control is difficult, 
// since you have to hand-code them.

// <Name>Types used in views should not implement IContract</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyViewAssembly" AND
  Implement "OPTIONAL:System.AddIn.Contract.IContract"

// Exposing a contract directly in the view can cause a variety of problems. 
// It makes it very difficult to version over time since it strongly binds 
// the consumer of the view to a particular version of the contract assembly.

// <Name>Concrete reference types used in views should be serializable</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyViewAssembly" AND
  IsClass AND
  !IsSerializable 

// Concrete types are very difficult isolate down the road. They should only 
// be in this assembly if they inherit/implement an abstract base class or interface 
// in this assembly. Other types should reference the abstract base class or 
// interface, and not the concrete helper type.

// <Name>Concrete reference types used in views should belong to a framework assembly</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyViewAssembly" AND
  IsClass AND
  !FullNameLike "^System." // The namespace name must begin with System. for framework type.

// Concrete types are very difficult isolate down the road. They should only be in 
// this assembly if they inherit/implement an abstract base class or interface in this 
// assembly. Other types should reference the abstract base class or interface, and not 
// the concrete helper type. You can pass types across the boundary directly only if 
// they are serializable and can be loaded in both sides of an isolation boundary. 
// This is only true for serializable framework types.

// <Name>Events should be of the generic type EventHandler<T></Name>
WARN IF Count > 0 IN SELECT FIELDS FROM ASSEMBLIES "MyViewAssembly" WHERE
  IsEventDelegateObject AND 
  !IsOfType "OPTIONAL:System.EventHandler<TEventArgs>"

// There are no tools that automatically generate adapters for events other
// than EventHandler<T> which would make building adapters for this member 
// very difficult.

// <Name>IList<T> should be used instead of arbitrary ICollections</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyViewAssembly" AND
  (Implement "OPTIONAL:System.Collections.Generic.ICollection<T>" OR
   Implement "OPTIONAL:System.Collections.ICollection")
  AND !FullNameIs "OPTIONAL:System.Collections.Generic.IList<T>"

// There are no pre-built contracts or adapters for collections other than IList<T>. 
// Thus, if you use these you will have to write your own adapters.

// <Name>Non-concrete types used in views should be defined in the view assembly</Name>
WARN IF Count > 0 IN SELECT TYPES OUT OF ASSEMBLIES "MyViewAssembly" WHERE
  IsDirectlyUsedBy "MyViewAssembly" AND
  (IsInterface OR IsAbstract)

// If you are using an interface/abstract base class defined in a different assembly,
// you need to ensure that that type follows the same rules that govern types in this assembly.

// <Name>Serializable types used by views should be defined in a framework assembly</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyViewAssembly" AND
  IsSerializable AND 
  !FullNameLike "^System." // The namespace name must begin with System. for framework type.

// If you intend to serialize this type across an isolation boundary, you need to be 
// sure that the type is going to be available to load in both sides of the isolation 
// boundary. This is hard to ensure if it is not a framework type.

// <Name>View members should not have open generic parameters</Name>
WARN IF Count > 0 IN SELECT METHODS FROM ASSEMBLIES "MyViewAssembly" WHERE
  IsGeneric 

// There are no tools to automatically generate pipelines for open generic types. 
// Thus, if you decide to isolate this type later you will have to do the adapter 
// logic by hand.

// <Name>Views should not use a type defined simply as System.Object</Name>
WARN IF Count > 0 IN SELECT TYPES WHERE
  IsDirectlyUsedBy "MyViewAssembly" AND
  FullNameIs "System.Object"

// Defining the type as System.Object makes it very difficult to ensure that
// it versions well over time. If this is intended to represent an arbitrary 
// contract type, you should use a more specific type instead.

// <Name>View members should not be marked static</Name>
WARN IF Count > 0 IN SELECT FIELDS FROM ASSEMBLIES "MyViewAssembly" WHERE
  IsStatic 

// The state of static types is stored per AppDomain, and changes to state 
// in one AppDomain are not reflected in others. Static types in the view are OK 
// as long as they provide simple helper functionality and are stateless.

42 on 49 rules can readily be expressed with CQL. Here are the ones that cannot be written with the current version of CQL :

(Contract)Arrays should not contain types that implement IContract ; (Contract)Arrays should only contain serializable types ; (View) Arrays should only contain serializable types : While you can constraint some methods to use some array or not with some regex on method signature and the term [], CQL cannot yet constraint element types of an array.

(Contract)Contract interfaces should not implement non-IContract interfaces : This rules implies 2 composite queries, the first one to get contract interfaces and the second one takes the result of the first one and check if it implements non-IContract interfaces. Composing queries this way is not yet possible with CQL but it is a major feature for the future.

(View) Concrete Reference Types Should Derive From A View Type Defined In The Current Assembly : Here also this rule need 2 composite queries to be implemented.

(Contract)Contract assemblies should not define events ; (View) Events should only be declared on Interfaces, not AbstractBaseClasses: While you can check if a class or a structure define some event by checking fields with the condition IsEventDelegateObject, CQL cannot so far check if an interface define some events.

Original Article at : http://feeds.feedburner.com/~r/CodeBetter/~3/336931612/rules-for-clr-add-ins-contract-and-view-assemblies.aspx

‘Defence in depth’ is a military strategy where the attacker is allowed to penetrate the defender’s lines, but is then gradually worn down by successive layers of defences. This strategy was famously used by the Soviet Army to halt the German blitzkrieg at the battle of Kursk, using a vast defensive network including trenches, minefields and gun emplacements. Defence in depth also has parallels in non-military applications. I use a defence in depth approach to detect bugs in my code. A bug has to pass through multiple layers of defences undetected before it can cause problems for my customers.

Layer 1: Compiler warnings

Compiler warnings can help to spot many potential bugs. Crank your compiler warnings up to maximum sensitivity to get the most benefit.

Layer 2: Static analysis

Static analysis takes over where compiler warnings leave off, examining code in great detail looking for potential errors. An example static analyser is Gimpel PC-Lint for C and C++. PC-Lint performs hundreds of checks for known issues in C/C++ code. The flip side of it’s thoroughness is that it can be difficult to spot real issues amongst the vast numbers of warnings and it can take some time to fine-tune the checking to a useful level.

Layer 3: Code review

A fresh set of eyes looking at your code will often spot problems that you didn’t see. There are various ways to go about this, including formal Fagan inspections, Extreme Programming style pair programming and informal reviews. There is quite a lot of documented evidence to suggest that this is one of the most effective ways to find bugs. It is also an excellent way to mentor less experienced programmers. But it is time consuming and can be hard on the ego of the person being reviewed. Also it isn’t really an option for solo developers

Layer 4: Self-checking

Of the vast space of states that a program can occupy, usually only a minority will be valid. E.g. it might makes no sense to set a zero or negative radius for a circle. We can check for invalid states in C/C++ with an assert() macro:

class Circle
{
    public:
        void setRadius( double radius );
    private:
        double m_radius;
}

void Circle::setRadius( double radius )
{
    assert( radius > 0.0 );
    m_radius = radius;
}

The program will now halt with a warning message if the radius is set inappropriately. This can be very helpful for finding bugs during testing. Assertions can also be useful for setting pre-conditions and post-conditions:

    void List::remove( Item* i )
    {
        assert( contains( i ) );
        ...
        assert( !contains( i ) );
    }

Or detecting when an unexpected branch is executed:

    switch ( shape )
    {
        case Shape::Square:
            ...
        break;

        case Shape::Rectangle:
            ...
        break;

        case Shape::Circle:
            ...
        break;

        case Shape::Ellipse:
            ...
        break;

        default:
            assert( false ); // shouldn't get here
        break;
    }

Assertions are not compiled into release versions of the software, which means they don’t incur any overhead in production code. But this also means:

• Assertions are not a substitute for proper error handling. They should only be used to check for states that should never occur, regardless of the program input.
• Calls to an assert() must not change the program state, or the debug and release versions will behave differently.

Different languages have different approaches, for example pre and post conditions are built into the Eiffel language.

Layer 5: Dynamic analysis

Dynamic checking usually involves automatically instrumenting the code in some way so that it’s runtime behaviour can be checked for potential problems such as: array bound violations, reading memory that hasn’t be written to and memory leaks. An example dynamic analyser is the excellent and free Valgrind for Linux. There are a few dynamic analysers for Windows, but they tend to be expensive. The only one I have tried in the last few years was Purify and it was flaky (do IBM/Rational actually use their own tools?).

Layer 6: Unit testing

Unit testing requires the creation of a test harness to execute various tests on a small unit of code (typically a class or function) and flag any errors. Ideally the unit tests should then be executed every time you make a change to the code. You can write your own test harnesses from scratch, but it probably makes more sense to use one of the existing frameworks, such as: NUnit (.NET), JUnit (Java), QUnit (Qt) etc.

According to the Test Driven Development approach you should write your unit tests before you write the code. This makes a lot of sense, but requires discipline.

Layer 7: Integration testing

Integration testing involves testing that different modules of the system work correctly together, particularly the interfaces between your code and hardware or third party libraries.

Layer 8: System testing

System testing is testing the system in it’s entirety, as delivered to the end-user. System testing can be done manually or automatically, using a test scripting tool.

Unit, integration and system testing should ideally be done using a coverage tool such as Coverage Validator to check that the testing is sufficiently thorough.

Layer 9: Regression testing

Regression testing involves running a series of tests and comparing the results to the same input data run on the previous release of the system. Any differences may be the result of bugs introduced since the last release. Regression testing works particularly well on systems that take a single input file and produce a single output file – the output file can just be diff’ed against the previous output.

Layer 10: Third party testing

Different users have different patterns of usage. You might prefer drag and drop, someone else might use right-click a lot and yet another person might prefer keyboard accelerators. So it would be unwise to release a system that has only ever been tested by the developer. Furthermore, the developer inevitably makes all sorts of assumptions about how the software will be used. Some of those assumptions will almost certainly be wrong.

There are a number of companies that can be paid by the day to do third party testing. I have used softwareexaminer.com in the past with some success.

Layer 11: Beta testing

End-user systems can vary in processor speed, memory, screen resolution, video card, font size, language choice, operating system version/update level and installed software. So it is necessary to test your software on a representative range of supported hardware + operating system + installed software. Typically this is done by recruiting users who are keen to try out new features, for example through a newsletter. Unfortunately it isn’t always easy to get good feedback from beta testers.

Layer 12: Crash reporting

If each of the above 11 layers of defence catches 50% of the bugs missed by the previous layer, we would expect only 1 bug in 2,048 to make it into production code undetected. Assuming your coding isn’t spectacularly sloppy in the first place, you should end up with very few bugs in your production code. But, inevitably, some will still slip through. You can catch the ones that crash your software with built-in crash reporting. This is less than ideal for the person whose software crashed. But it allows you to get detailed feedback on crashes and consequently get fixes out much faster.

I rolled my own crash reporting for Windows and MacOSX. On Windows the magic function call is SetUnhandledExceptionFilter. You can also sign up to the Windows Winqual program to receive crash reports via Windows’ own crash reporting. But, after my deeply demoralising encounter with Winqual as part of getting the “works with Vista” logo, I would rather take dance lessons from Steve Ballmer.

Test what you ship, ship what you test

A change of a single byte in your binaries could be the difference between a solid release and a release with a showstopper bug. Consequently you should only ship the binaries you have tested. Don’t ship the release version after only having tested the debug version and don’t ship your software after a bug fix without re-doing the QA, no matter how ‘trivial’ the fix. Sometimes it is better to ship with minor (but known) bugs than to try to fix these bugs and risk introducing new (and potentially much worse) bugs.

Cross-platform development

I find that shipping my software on Windows and MacOSX from a single code base has advantages for QA.

• different tools with different strengths are available on each platform
• the Gnu C++ compiler may warn about issues that the Visual Studio C++ compiler doesn’t (and vice versa)
• a memory error that is intermittent and hard to track down on Windows might be much easier to find on MacOSX (and vice versa)

Conclusion

For the best results you need your layers of checks to be part of your day-to-day development, not something you do just before a release. This is best done by automating them as much as possible, e.g.:

• setting the compiler to treat warnings as errors
• performing static analysis and unit tests on code check-in
• running regression tests on the latest version of the code every night

Also you should design your software in such a way that it is easy to test. E.g. building in log file output can make it much easier to perform regression tests.

Defence in depth can find a high percentage of bugs. But obviously the more bugs you start with the more bugs that will end up in your code. So it doesn’t remove the need for good coding practices. Quality can’t be ‘tested in’ to code afterwards.

I have used all 12 layers of defence above at some point in my career. Currently I am not using static analysis (I must update that PC-Lint licence), code review (I am a solo developer) and dynamic analysis (I don’t currently have a dynamic analyser for Windows or MacOSX). I could also do better on unit testing. But according to my crash reporting, the latest version of PerfectTablePlan has crashed just three times in the last 5000+ downloads (the same bug each time, somewhere deep down in the Qt print engine). Not all customer click the ‘Submit’ button to send the crash reports and crashes aren’t the only type of bug, but I think this is indicative of a good level of quality. It is probably a lot better than most of the other consumer software my customers use[1]. Assuming the crash reporting isn’t buggy, of course…

Original Article at : http://successfulsoftware.net/2008/07/09/using-defence-in-depth-to-produce-high-quality-software/

I have put a very early preview release of CSLA Light and CSLA .NET 3.6 online at www.lhotka.net/cslalight/download.aspx.

There is no sample app at this point, so you’ll have to look at the unit tests in cslalighttest and cslatest to figure out how to use the various features.

Obviously this is very early code, but it is healthy to release early and often, so here we go

One side-effect of our work with CSLA Light is that we discovered that testing asynchronous methods is really hard with nunit and MSTest, and impossible with the Silverlight unit test framework provided by Microsoft. And yet in Silverlight, async methods are commonly required, and for parity a number of async features are now also in CSLA .NET. And we need to have unit tests for them.

To address this issue, we ended up creating our own Silverlight unit testing framework, and an add-on framework for nunit or MSTest. This allows us to write a common set of test code that runs in both Silverlight and .NET so we can test both, and establish that we have parity between them.

Earier today, Justin split this testing framework out of CSLA and we put it up on CodePlex, calling it UnitDriven. The CSLA Light project and Magenic are donating the code to the community as an open-source project, because it can be used to build async unit tests for any app, not just for CSLA Light.

Original Article at : http://www.lhotka.net/weblog/CSLALightPreviewRelease.aspx