DAL.Лучшая практика моделирования ограничений данных - PullRequest
Новая
       8

DAL.Лучшая практика моделирования ограничений данных

1 голос
/ 22 августа 2010

Данные хранятся в реляционной базе данных с ограничениями данных (например, максимальная длина свойства строки). Клиенты используют библиотеку доступа к данным (DAL) для управления данными в режиме ORM (репозитории + классы предметной области)

Где бы вы лично внедрили ограничения? Например:

Классы предметной области: 

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

Или может быть хранилище: 

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

Или, может быть, вы будете использовать атрибуты, назначенные свойствам классов предметной области, которые будут обрабатываться в методах репозитория посредством отражения для автоматического усечения строковых полей. 

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

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

Или может быть что-то еще?

Заранее спасибо!

Ответы [ 3 ]

1 голос
/ 22 августа 2010

Я бы сделал это на уровне бизнес-логики с классом бизнес-логики, который отличается от классов, связанных с базой данных.Я бы не стал выдавать ошибку sql или даже применять ее в базе данных.На мой взгляд, база данных должна касаться только формы и согласованности данных.Не с самими фактическими данными.

Ваше правило, состоящее из 50 символов, является бизнес-правилом, а не логическим, реляционным или "структурным" правилом.С таким же успехом это может быть 51 символ или 49. Вы произвольно выбрали 50, что хорошо.Вот для чего существуют объекты бизнес-уровня.Для обеспечения соблюдения этих правил.

Любой бизнес-доступ к вашим данным должен быть снова через бизнес-уровень, предоставленный через сервисы, прямые ссылки или какой-либо другой метод, который вы выберете.Доступ к вашей базе данных должен снова быть предметом, который заботится о форме и согласованности ваших данных, а не самих данных.Такие вещи, как резервное копирование, репликация, кластеризация, распределение нагрузки, аудит и т. Д.

Таким образом, классы ORM являются просто связующим звеном между бизнес-объектом Person и хранением Person в реальной базе данных.База данных должна заботиться только об общей форме и структуре базы данных и базовой инфраструктуре и механизмах фактического хранения данных.Бизнес-объект должен определять «природу» объекта и определять, что это такое на самом деле.Что у Человека всегда должно быть по крайней мере имя, что его возраст не может превышать 110 лет, его рост не может превышать 7 футов и т. Д. И т. Д.

Так или иначе, такова моя философия / правило: -)

1 голос
/ 22 августа 2010

Ограничения являются частью проверки.Бизнес-уровень отвечает за проверку объектов, но также удобно использовать ту же логику проверки в пользовательском интерфейсе.Способ поделиться такой логикой состоит в том, чтобы использовать некоторый API, который помечает ваши объекты данных с атрибутами проверки.Вы можете запустить ту же проверку в BL и UI.DataAnnotations предлагает эту функцию, и ее также можно реализовать с помощью блока приложения Validation.

Редактировать: Это не означает, что вы не будете помещать ограничения в БД.Это означает лишь то, что вы должны быть в состоянии обнаружить нарушение ограничения как можно скорее, чтобы сохранить обратную передачу в базу данных.

0 голосов
/ 22 августа 2010

В базе данных мои предпочтения.
Если кто-то попытается вставить слишком длинную строку, будет возвращена ошибка SQL.Приложение должно обрабатывать эту ошибку, отображая пользователю полезное сообщение.

Оно также централизовано на случай, если у кого-то есть альтернативный доступ - SSMS или другой код приложения.

...