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 against it - for two reasons.
The first was that it was proving tricky to use in a testable manner. It could well be that with perseverance I could have got around this, but it seems that the architecture employed (static methods, encapsulated business and data access) made separation of concerns and mocking/unit testing difficult.
Second was really just a nagging feeling that a lot of the features I would never be likely to use - particular those geared to Windows Forms. The mechanism supports n-level undo, remoting objects and the retrieval and saving of large object graphs - none of which I could see a likely scenario that I would require in the medium term.
Validation Framework
One great thing CSLA.Net would have provided though was a consistent means of handling business object validation - and so this is what I looked to replicate in the solution.
Much of the credit here really needs to go to the author of the recently released ASP.Net MVC Framework book from APress. I can certainly recommend this book highly - it does a great job of explaining not only the MVC framework, but also the patterns techniques deployed in the domain model layer, namely repositories and inversion of control/dependency injection.
The crux of the validation framework I've employed on this project, and no doubt on an ongoing basis, is that a particular business object or entity (e.g. a Customer object) may be validated agaist three groups of criteria:
- Self-validation. This would be anything that the simply entity class can validate about itself (e.g. required fields, ranges of valid values, internal field comparisons)
- External validation. This would be business rules enforced based on factors outside of the immediate properties and methods of the class (e.g. user authorisations)
- Database validation. These are really a special class of external validation that is enforced in the database (e.g. dependent records for deletions, unique fields).
The business objects or entities are deliberately implemented as simply as possible. They only contain properties, methods that can act on internal fields only (e.g. an Order class that calculated it's own total would be a good candidate), and methods to implement an interface I've set up to enforce consistent self-validation:
1 using System;
2 using System.Collections.Specialized;
3
4 namespace DomainModel.Interfaces
5 {
6 /// <summary>
7 /// Interface for all entity classes that perform self-validation
8 /// </summary>
9 interface IValidatingEntity
10 {
11 NameValueCollection GetRuleViolations();
12 }
13 }
1 using System;
2 using System.Collections.Specialized;
3 using DomainModel.Interfaces;
4
5 namespace DomainModel.Entities
6 {
7 /// <summary>
8 /// Class representiting a Title entity and it's self-validation rules
9 /// </summary>
10 public class Customer : IValidatingEntity
11 {
12 public int Id { get; set; }
13 public string Name { get; set; }
14
15 /// <summary>
16 /// Checks class internal members are valid
17 /// </summary>
18 /// <returns>Dictionary of any valuations (property/message)</returns>
19 public NameValueCollection GetRuleViolations()
20 {
21 NameValueCollection errors = new NameValueCollection();
22
23 if (string.IsNullOrEmpty(Name))
24 errors.Add("Name", "Name is a required field.");
25 else
26 if (Name.Length > 100)
27 errors.Add("Name", "The Name field must be 100 characters or less.");
28
29 return errors;
30 }
31 }
32 }
My data access layer is implemented using repositories for each area of the application - in this case a Customer repository that implements an interface:
1 using System;
2 using DomainModel.Entities;
3
4 namespace DomainModel.Repository.Abstract
5 {
6 /// <summary>
7 /// Interface for Customers repository
8 /// </summary>
9 public interface ICustomersRepository
10 {
11 IList<Customer> GetCustomerList();
12 Customer GetCustomer(int id);
13 void UpdateCustomer(Customer title);
14 }
15 }
1 using System;
2 using System.Data;
3 using System.Data.SqlClient;
4 using DomainModel.Entities;
5 using DomainModel.Repository.Abstract;
6
7 namespace DomainModel.Repository.Concrete
8 {
9 /// <summary>
10 /// Customers repository implemented using SQL ADO.Net data access methods
11 /// </summary>
12 public class SqlCustomersRepository : ICustomersRepository
13 {
14 private string connectionString;
15
16 public SqlCustomersRepository(string connectionString)
17 {
18 this.connectionString = connectionString;
19 }
20
21 /// <summary>
22 /// Persists a Customer object to the database
23 /// </summary>
24 /// <param name="customer">Customer object</param>
25 public void UpdateCustomer(Customer customer)
26 {
27 using (SqlConnection cn = new SqlConnection(connectionString))
28 {
29 SqlCommand cm = cn.CreateCommand();
30 cm.CommandType = CommandType.StoredProcedure;
31 cm.CommandText = "updateCusomter";
32 cm.Parameters.AddWithValue("@id", customer.Id);
33 cm.Parameters.AddWithValue("@name", customer.Name);
34 cn.Open();
35 cm.ExecuteNonQuery();
36 cn.Close();
37 }
38 }
39 }
40 }
Finally, acting as the bridge between the repository and the UI layer sits a service layer:
1 using System;
2 using DomainModel.Entities;
3
4 namespace DomainModel.Service.Abstract
5 {
6 /// <summary>
7 /// Interface for Customers service
8 /// </summary>
9 public interface ITitlesService
10 {
11 IList<Customer> GetCustomerList();
12 Customer GetCustomer(int id);
13 void UpdateCustomer(Customer title);
14 }
15 }
1 using System;
2 using System.Collections.Generic;
3 using System.Linq;
4 using System.Text;
5 using System.Collections.Specialized;
6 using DomainModel.Entities;
7 using DomainModel.Service.Abstract;
8 using DomainModel.Repository.Abstract;
9 using DomainModel.Exceptions;
10 using DomainModel.Interfaces;
11
12 namespace DomainModel.Service.Concrete
13 {
14 /// <summary>
15 /// Customers service layer
16 /// </summary>
17 public class CustomersService : ICustomersService
18 {
19 private ICustomersRepository repository;
20
21 public CustomersService(ICustomersRepository repository)
22 {
23 this.repository = repository;
24 }
25
47 /// <summary>
48 /// Validates (at entity, service and database level) and saves a Customer object
49 /// </summary>
50 /// <param name="customer">Customer object</param>
51 /// <param name="user">User making the update</param>
52 public void UpdateCustomer(Customer customer, User user)
53 {
54 NameValueCollection errors = customer.GetRuleViolations();
55 GetServiceViolations(ref errors, user);
56 if (errors.Count > 0)
57 throw new RuleException(errors);
58 try
59 {
60 repository.UpdateCustomer(customer);
61 }
62 catch (Exception ex)
63 {
64 if (GetDatabaseViolations(ex, ref errors))
65 throw new RuleException(errors);
66 else
67 throw (ex); // Throw original error if not handled
68 }
69 }
70
71 /// <summary>
72 /// Checks any service level business rules
73 /// </summary>
74 /// <param name="errors">Existing collection of errors</param>
75 private void GetServiceViolations(ref NameValueCollection errors, User user)
76 {
77 if(!user.IsInRole("Edit"))
78 errors.Add("Authorisation", "Your account is not authorised to perform this action.");
79 }
80
81 /// <summary>
82 /// Handles a database exception triggered after a save.
83 /// </summary>
84 /// <param name="ex">Exception triggered by database save</param>
85 /// <param name="errors">Existing collection of errors</param>
86 /// <returns>Flag for if any handled database exceptions found</returns>
87 private bool GetDatabaseViolations(Exception ex, ref NameValueCollection errors)
88 {
89 bool handledError = false;
90 if (ex.Message.IndexOf("UIX_Customers_Name") >= 0)
91 {
92 errors.Add("Database Constraint", "Names of Customers must be unique.");
93 handledError = true;
94 }
95 return handledError;
96 }
97 }
Which can be then brought into the UI layer and represented in the by copying them to the ModelStateDictionary, and hence hooking up with the MVC Framework's standard means of displaying validation errors in views. This last step is best implemented as an extension method in the UI layer, to avoid fixing a dependency on MVC in the domain model.
1 using System;
2 using System.Collections.Generic;
3 using System.Web;
4 using System.Web.Mvc;
5 using DomainModel.Exceptions;
6
7 namespace WebUI.ExtensionMethods
8 {
9 /// <summary>
10 /// MVC project extension methods
11 /// </summary>
12 public static class ExtensionMethods
13 {
14 /// <summary>
15 /// Extends RuleException (defined in domain model) with a method to copy it's contents to the MVC
16 /// ModelStateDictionary
17 /// </summary>
18 /// <param name="ex">Rule exception object to apply extension to</param>
19 /// <param name="modelState">MVC model state dictionary</param>
20 /// <remarks>
21 /// Implemented in web project to avoid MVC dependency in domain model layer.
22 /// </remarks>
23 public static void CopyToModelState(this RuleException ex, ModelStateDictionary modelState)
24 {
25 foreach (string key in ex.Errors)
26 foreach (string value in ex.Errors.GetValues(key))
27 modelState.AddModelError(key, value);
28 }
29 }
30 }
The resulting controller action, that calls the validation and save of the Customer object looks like this:
42 [AcceptVerbs(HttpVerbs.Post)]
43 public ActionResult Edit(Customer title)
44 {
45 if (ModelState.IsValid)
46 {
47 try
48 {
49 titlesService.UpdateCustomer(title);
50 }
51 catch (RuleException ex)
52 {
53 ex.CopyToModelState(ModelState);
54 }
55 }
56 if (ModelState.IsValid)
57 return RedirectToAction("List");
58 else
59 return View("Edit", title);
60 }
In summary, I think this going to prove a simple but easily adhered to and and clear pattern for centralised business rules. Will post further once it has been put through its paces in a real application.
Comments
Post a Comment