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

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

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

S>Т.е. объект с "изменяющимся видом" и кучей интерфейсов не считается навороченным? И с ним, наверное, очень просто работать (интуитивно понятно, так сказать).
Допустим, у тебя есть набор полей в форме, которое переводится в бизнес-объект с клиентской бизнес-логикой, которое переводится в некоторый объект DTO, которое переводится в бизнес-объект доменной модели, которое в свою очередь переводится в набор строк в базе данных. Никакой кучи интерфейсов. Просто состояние объекта находится в том виде, которое нужно в данный момент. Естественно данный список приведен от балды.

S>А потом, я всегда рассуждаю так: есть объект и есть остальная система, которая им пользуется. Так что функциональность разделяется. Но, ту функциональность, которая на объект возложена, он должен выполнять качественно, т.е. не давать перевести себя в невалидное состояние (невалидное, с точки зрения самого объекта).
Бизнес-логика которая на клиенте, и бизнес-логика которая на сервере(пускай это даже сервер БД) разные. У них не просто разные возможности, но и разные цели.

S>Например, выше описанный Address:
S>Его смысл состоит в представлении информации о адресе, исходя из этого он (объект) и должен делать валидацию себя. Одной подсистеме, использующей данный объект может и не нужно знать существует ли такой адрес в реальности, а другой — нужно, исходя из этого подсистема делает (или не делает) соответствующую проверку.
S>И основная мысль в том, что эта проверка никоим образом к бизнес объекту не относится, она относится к способу использования этого бизнес объекта в конкретной подсистеме.

S>Поэтому получаются две совершенно разные валидации:
S>

S>- валидация самого объекта
S>- валидация состояния системы по завершению бизнес транзакции
S>

S>Причем вторая не столь формализуема как первая.
Давай классифицируем когда происходит валидация данных на форме. Есть 3 случая:
1. При вводе каждого символа. Например, бизнес задачей определено что в данном поле может быть только цифра. Тогда поле не должно воспринимать ничего кроме нажатие на клавиши с цифрами.
2. При потере фокуса. Если неверное значение, то фокус не должен уходить
3. Перед отправлением объекта на другой уровень.
1-2 случаи логикой бизнес-объекта не управляются. В случае создания нового бизнес-объекта, его может еще и не сущестовать. Плюс к этому, значения выбранные из справочника — вообще незачем на клиенте валидировать.
Более криминальный случай, например:
у тебя объект должен показываться иконкой в зависимости от значения. И на разных формах(клиентах) показ поля разный. Так что запихнуть всю бизнес логику на бизнес-объект, даже на уровне клиента не удастся.


GZ>>Бизнес-правила разные для форм и для бизнес-логики.

S>Но есть бизнес объект с которым работает и форма и бизнес логика. И валидация с точки зрения самого объекта должна быть одна и та же.
Частично да. Но например не обязательно объекты бизнес логики должны пользоваться функционалом бизнес-объекта. В случае уровня 3, легче проверять объект от а до я(или от a to z) полностью. Особенно в случае доменной модели. На 4 уровне — это может быть обязательным условием.

GZ>>Даже если ты описываешь операцию валидирования, многие операции можно выполнить только на 3 и 4 уровне.

S>На третьем — да, об этом я написал выше в данном посте, но повторюсь, что это не валидирование объекта, а валидирование способа его использования в како-либо подсистеме.
S>Четвертый уровень — только физический. Никакой дополнительной логической нагрузки он не несет. В нормальном фреймворке с базой напрямую никто и работать-то не должен, только с бизнес объектами и специальным языком запросов. А то, что в реальности некоторые проверки удобно выполнять в СУБД (ссылочную целостность, например), так это только оптимизация (ну и еще успокоение нервов админа СУБД), их принципиально можно делать и сервере приложений.

Если данные используемые при проверке больше чем оперативная память, то принципиально нельзя.

GZ>>Если, конечно, тебе не хватает функциональности System.Data.DataSet.

S>Вот люди. Я с ними как с художниками, про новый движок, про специальный язык, а они... Ширее надо мыслить .
Не ширее а ширше. Диревня.
Функциональность датасета (или вернее сказать xsd) достаточно продвинута и достаточна. Еще добавить регуляры, то вообще был бы класс.

С уважением, Gleb.