The consequences for not defining coding guidelines at the beginning of a project are not that obvious at first. The reason for it is that we pay the price later in the maintenance phase; after the product went live. I.e. a theoretically small change request turns into possibly huge implementation problems. This is especially true when the original development team is long gone and the maintenance team is trying to make sense of the code in front of them.

Coding Guidelines:
Development guidelines have to be short and easy to understand (developers don't like to read, they rather code) and have to contain a set of general, restrictive rules. But keep in mind, guidelines are a work in progress since one does not know all the details and pitfalls of a new technology in advance.

Goals:

• Easy maintenance: avoid code duplications! The rules can be executed from different places, but the implementation exists only once.
• Simple usage:from a coding perspective the flow of a user request back to the respond must be easy to understand and non intrusive. For example, filters depend on the authenticated user. It is mandatory that the user information travels implicitly with the request. I.e. no method has a user as a parameter defined, but anywhere in the architecture the code has access to the authenticated user information and ultimately knows who the user is that issued the request.
• Great end user experience: end users are happy when an application reacts fast and messages, success or errors, are clear and understandable.

The following high-level diagram lists components and programming artifacts in which business rules could possibly be implemented (I am sure there are even more areas). Below the diagram, we then define where to place business rule code.

• DS Interceptors: ADO.NET Data Services has the plumbing already built in. There are two interceptors available:
  The Query Interceptor for Filters and the Change Interceptor for our Validators. Here two examples:

       [QueryInterceptor("Orders")]
       public Expression

      [ChangeInterceptor("Category")]
      public void OnChangeCategories(Category c, UpdateOperations ops)
      {
            if (ops == UpdateOperations.Add || ops == UpdateOperations.Change)
            {
               // Note: just for demonstration purposes, 
// see comments in Model section below
                if (c.Name.Contains(" "))
                {
                    throw new DataServiceException(400,
                                "Category names must consist of a single word");
                }
                // if no error found, simply return and the Category will be
                // inserted/updated
            }
        }

• Model: for reusability purposes, the actual validation code from the above example (see note) should be implemented in a partial class of the Entity Models and be executed from the interceptors only. Also, the validation code must return ALL errors at once, not raising an exception immediately for each validation error it encounters.  

The exceptions:

• Schema: you might want to add the column and relation restrictions into the schema definition, especially when you have backend processes that do data entry without going through the data service layer. With the new EF implementation from Microsoft which generates schema definitions from your Domain Model this will not be an issue.
• JavaScript: simple validation of screen data inputs for completeness and formatting can enhance the user experience. But remember, it is only a partial validation and the real validation will happen in the Data Service layer. In addition, for every business rule change request the programming code needs to be updated in two places. 

Where no business rule should be implemented:

• Stored Procedures: I can't think of a reason why someone should have business rule logic in stored procedures; it only makes debugging harder, much harder.
• EF Interceptors: In this architecture, we assume there is only one consumer of the EF layer. So, no need to duplicate the logic in the EF layer.
• View:I can't think of a reason why we should have it in here either.
• Controller: No need to have any validation code or filter code in the controller.