DAL. Modelling data constraints best practice

Question

Data stored in relation database with data constraints (for example maximum string property length). Clients use Data Access Library (DAL) to manage the data in ORM manner (repositories + data domain classes)

Where would you personally implement constraints? For example:

Data domain classes:

class Person
{
 private string _name;
 public string Name 
 {
   get { return _name; }
   set { _name = StringHelper.Truncate(value, 50) }
 }
 ...
}

Or may be repository:

PersonRepository {
  public void CreatePerson(Person p) {
    p.Name = StringHelper.Truncate(p.Name, 50);
    ... 
    DataContext.Insert(..);
  }
}

Or may be you shall use attributes assigned to data domain classes properties that would be processed in repository methods via reflection for automated string fields truncation.

class Person {
   [StringConstraint(MaxLength = 50)]
   public string Name { get; set; }
} 

PersonRepository::CreatePerson(p) {
  EntityHelper.ApplyConstraints(p);
  ...
}

Or may be something else?

Thank you in advance!

Answer 1

In the database is my preference.
If someone attempts to insert a string that's too long, a SQL error will be returned. It's up to the application to handle that error by displaying a useful msg to the user.

It's also centralized in case someone has alternate access - SSMS, or other application code.

Answer 2

I would do it in the business logic layer, with a business logic class that is different from the database related classes. I wouldn't bubble up the sql error or even enforce it in the database. In my opinion the database should only be concerned with the shape and consistency of the data. Not with the actual data itself.

Your rule about 50 characters is a business rule, not a logical, relational or "structural" rule. It could just as easily be 51 characters or 49. You arbitrarily picked 50, which is fine. That is what the business layer objects are there for. To enforce those rules.

Any business access to your data, should again be through the business layer, exposed via services, direct reference or some other method you choose.

The only "direct" access to your database should again be things which care about the shape and consistency of your data, not the actual data itself. Things like backup, replication, clustering, load balancing, auditing etc.

So the ORM classes are just the glue between a business object of Person and the storage of Person in an actual database. The database should only care about the overall shape and structure of the database and the underlying infrastructure and mechanics of the actual data storage. The business object should determine the "nature" of the object and define what it truly is. That a Person should always have at least a firstname, that their age cannot be greater than 110 years, their height cannot be more than 7 feet, etc. etc.

Thats my philosophy/rule of thumb anyway :-)

Answer 3

Constraints are part of validation. It is responsibility of Business layer to validate objects but it is also convenient to use same validation logic in UI. The way to share such logic is to use some API which marks your data objects with validation attributes. You can than run the same validation in BL and UI. DataAnnotations offers this functionality and it can be also achieved with Validation application block.

Edit: It doesn't mean that you will not place constraints in DB. This only mean that you should be able to detect constraint violation as soon as possible to save the round trip to database.