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

Question

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

Данные хранятся в базе данных отношений с ограничениями данных (например, максимальная длина свойства строки). Клиенты используют библиотеку доступа к данным (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);
  ...
}

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

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

1

.net orm data-access-layer

задан Andrew Florko 22 August 2010 в 05:22

3 ответа

Другие вопросы по тегам:

.net orm data-access-layer

Похожие вопросы:

score 1 · Answer 1

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

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

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

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

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

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

score 1 · Answer 2

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

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

score 0 · Answer 3

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

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