Andy Butland

Following on from the previous post describing a validation framework I'm planning to use on MVC projects, this post extends the development to incorporate a range of tests. To recap, I've set up a domain model structure that consists of: Entities - simple classes representing the fields and relationships of my business objects. They consist of properties and methods that act only on those properties (i.e. they have no external dependencies. Repository layer - a number of data access methods that provide CRUD methods for retrieving and data from the database and instantiating the entities, and persisting their changes back. Service layer - a layer consisting of methods that sit between the UI and repository layer, passing method calls and objects in between. These classes combine to provide validation at three levels: Entity validation - these are C# methods defined on the entity object itself to internally validate its fields. They will consist of checks for required fields...

The most recent project I've started to work on is going to require a number of web front-ends for a business. There will be a single database, from which information will be drawn and written to in various ways on the different websites. This situation suggests a robust means of applying and enforcing business rules and validation within a common business logic layer ; promoting code re-use across the sites and avoiding the maintenance headache of having rules in the UI layer. Due to a delayed start of the project, I've had a bit of time to investigate some different options to solve this - and to have a hard look at some of the techniques that have been used in the past where, if I'm honest, this wasn't always best achieved. CSLA.Net Firstly, I spent a bit of time with CSLA.Net . This is a robust, tried-and-tested framework for implementing your business objects. It's very powerful and I'm sure would prove a good solution. However in the end I decided aga...