Здравствуйте, Jack128, Вы писали:

S>>Если у вас с базой работает только ваша система — это вопрос вкуса. Если несколько — попробуйте обойтись
J>а в чем проблема? Всю логику в хп перенести и готово.

Представления данных будут различаться для разных систем. Придётся или дублировать код, или ввести ХП чисто для валидации и дёргать их из хранимок доступных конкретному приложению.
Это оверкилл, тем более что забытая в любой хранимке проверка ломает всю систему.

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

Чем они вообще полезны? Как проверка на скажем обязательность фамилии в классе Покупатель станет лучше/удобнее если ее вынести куда-то во фрейворк?

Здравствуйте, Аноним, Вы писали:

А>Чем они вообще полезны? Как проверка на скажем обязательность фамилии в классе Покупатель станет лучше/удобнее если ее вынести куда-то во фрейворк?


Имхо, такие проверки должны быть обязательно на "последнем фронте" — в триггерах БД/проверках при коммите в DAL(если с триггерами никак). Иначе в СУБД рано или позно окажется мусор.

Валидация в UI (а куда без неё?) обычно делаются силами самого UI-фреймворка. Остаются ассерты — им как раз самое место в классах БЛ/данных. По хорошему без них тоже никак — замучаетесь отслеживать точку, в которой в класс попали некорректные данные. Куда тут можно прикрутить целый фрейморк валидации — я не знаю.

*мы в форуме про архитектуру, так?
Вы уверены, что наличие фамилии в классе Покупатель — это вообще хорошая идея? Как быть с покупками на юрлицо?

Здравствуйте, Аноним, Вы писали:

А>Чем они вообще полезны? Как проверка на скажем обязательность фамилии в классе Покупатель станет лучше/удобнее если ее вынести куда-то во фрейворк?
Я на проекте пользовал FluentValidation
Т.к. модель была достаточно простая и композитная то можно было написать правила которые бы ее проверяли перед последующим сохранением..
Но все зависит от задач .. если у вас модель сложнее и ее валидация завязана на сторонние сервисы и вы хотите вынести ее валидацию в отдельный модуль то может посмотреть в сторону скриптовых языков и на них писать валидацию модели..

Здравствуйте, Sinix, Вы писали:

S>Имхо, такие проверки должны быть обязательно на "последнем фронте" — в триггерах БД/проверках при коммите в DAL(если с триггерами никак). Иначе в СУБД рано или позно окажется мусор.

S>Валидация в UI (а куда без неё?) обычно делаются силами самого UI-фреймворка. Остаются ассерты — им как раз самое место в классах БЛ/данных. По хорошему без них тоже никак — замучаетесь отслеживать точку, в которой в класс попали некорректные данные. Куда тут можно прикрутить целый фрейморк валидации — я не знаю.

речь идет про валидацию в доменной модели. Понятно что до определенного уровня валидация есть и в базе данных и в UI, но меня интересует именно применение фреймворков в бизнес-слое

S>*мы в форуме про архитектуру, так?
S>Вы уверены, что наличие фамилии в классе Покупатель — это вообще хорошая идея? Как быть с покупками на юрлицо?

будет другой подтип это только пример

Здравствуйте, Jericho113, Вы писали:

J>Здравствуйте, Аноним, Вы писали:

А>>Чем они вообще полезны? Как проверка на скажем обязательность фамилии в классе Покупатель станет лучше/удобнее если ее вынести куда-то во фрейворк?
J>Я на проекте пользовал FluentValidation
J>Т.к. модель была достаточно простая и композитная то можно было написать правила которые бы ее проверяли перед последующим сохранением..
J>Но все зависит от задач .. если у вас модель сложнее и ее валидация завязана на сторонние сервисы и вы хотите вынести ее валидацию в отдельный модуль то может посмотреть в сторону скриптовых языков и на них писать валидацию модели..

вот собственно и вопрос про то зачем такие фрейворки существуют? Вот этот FluentValidation чем-то помог? Облегчил написание логики или еще чего-нибудь полезного с собой привнес? Я пытаюсь понять для чего их применяют, например вот из ссылки про вышеуказанны валидатор:

public class CustomerValidator: AbstractValidator<Customer> {
  public CustomerValidator() {
    RuleFor(customer => customer.Surname).NotEmpty();
    RuleFor(customer => customer.Forename).NotEmpty().WithMessage("Please specify a first name");
    RuleFor(customer => customer.Company).NotNull();
    RuleFor(customer => customer.Discount).NotEqual(0).When(customer => customer.HasDiscount);
    RuleFor(customer => customer.Address).Length(20, 250);
    RuleFor(customer => customer.Postcode).Must(BeAValidPostcode).WithMessage("Please specify a valid postcode");
  }

Ведь я ту-же логику могу и непосредственно в Customer'e написать? В чем выгода?

Здравствуйте, Аноним, Вы писали:

А>речь идет про валидацию в доменной модели. Понятно что до определенного уровня валидация есть и в базе данных и в UI, но меня интересует именно применение фреймворков в бизнес-слое
Ну... тогда это самые обычные ассерты, в модель редко помещается какая-либо логика, так что ничего серьёзнее

public decimal Weight
{
  get ...
  set
  {
    Code.Positive(value, "Weight");
    ...
  }
}

...

[DebuggerHidden]
public static void Positive(decimal argument, string argumentName)
{
  if (argument < 0)
  {
    if (Debugger.IsAttached) Debugger.Break();
    throw new ArgumentOutOfRangeException(...)
  }
}

тут абсолютно не требуется.

Здравствуйте, Аноним, Вы писали:

А>Ведь я ту-же логику могу и непосредственно в Customer'e написать? В чем выгода?

Ну для меня выгода была в том что вместо мешанины if then else if кусков получить код который нормально читается и поддерживается, у меня логика валидации была достаточно
сложной — валидация полей коллекции и валидация самих коллекций.


Если логика простая то можно и в Customer классе написать это уж вам решать — просто что бы разобраться в самописном валидаторе то имхо больше времени потратит тот кто будет
после вас разбираться и дописывать.

Здравствуйте, Sinix, Вы писали:

S>Имхо, такие проверки должны быть обязательно на "последнем фронте" — в триггерах БД/проверках при коммите в DAL(если с триггерами никак). Иначе в СУБД рано или позно окажется мусор.

Триггеры в топку!

Здравствуйте, koandrew, Вы писали:

K>Триггеры в топку!

Если у вас с базой работает только ваша система — это вопрос вкуса. Если несколько — попробуйте обойтись

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, koandrew, Вы писали:

K>>Триггеры в топку!

S>Если у вас с базой работает только ваша система — это вопрос вкуса. Если несколько — попробуйте обойтись

а в чем проблема? Всю логику в хп перенести и готово.

Здравствуйте, Аноним, Вы писали:

А>Ведь я ту-же логику могу и непосредственно в Customer'e написать? В чем выгода?
В том, что это позволяет
а) не трогать Customer каждый раз, когда требования изменятся.
б) иметь столько правил валидации, сколько нужно — например, по одному на каждый сценарий (вместо одного правила, которое никого не устроить)
в) в хорошем Фреймворке, эти правила можно многократно повторно использовать. Например, генерировать по ним javascript-валидаторы на клиенте, валидаторы в коде API, валидаторы в базе (ХП/триггеры/check constrain-ты). А это позволяет избежать беготни по куче исходников в случае, когда допустимая длина адреса внезапно вырастет до 500 символов.