Обычно при описании трехзвенной архитектуры всегда говорят о том, что сервер приложений "общается" с клиентом бизнес-объектами, а с сервером базы — на языке SQL.
Но при таком подходе получается, что клиент должен как минимум знать о интерфесах бизнес-объектов и, возможно бизнес-классов, которые умеют что-то выполнять с объектами. И изменения в структуре бизнес-объектов ведут к пересборке и обновлению всех клиентов, знающих о этом интерфейсе.
А нет ли каких хитрых путей, позволяющих сделать интерфейсы бизнес-объектов невидимыми для клиента? Так, чтобы клиент при этом получал некий набор простейших типов (string, DateTime, int, double), давал возможность пользователю просмотреть значения, исправить и отправить обратно на сервер? Где уже набор типов будет превращен в бизнес объект, проверен и сохранен в базу (например)?
Здравствуйте, oleksab, Вы писали:
O>Добрый день
O> Обычно при описании трехзвенной архитектуры всегда говорят о том, что сервер приложений "общается" с клиентом бизнес-объектами, а с сервером базы — на языке SQL. O> Но при таком подходе получается, что клиент должен как минимум знать о интерфесах бизнес-объектов и, возможно бизнес-классов, которые умеют что-то выполнять с объектами. И изменения в структуре бизнес-объектов ведут к пересборке и обновлению всех клиентов, знающих о этом интерфейсе.
Для устранения данной проблемы используют подход, основанный на толерантности транспортного протокола.
O> А нет ли каких хитрых путей, позволяющих сделать интерфейсы бизнес-объектов невидимыми для клиента? Так, чтобы клиент при этом получал некий набор простейших типов (string, DateTime, int, double), давал возможность пользователю просмотреть значения, исправить и отправить обратно на сервер? Где уже набор типов будет превращен в бизнес объект, проверен и сохранен в базу (например)?
BO упаковываются в DTO — так клиент общается с промежуточным звеном.
O> Имеет ли вообще смысл такой подход?
Здравствуйте, oleksab, Вы писали:
O> Обычно при описании трехзвенной архитектуры всегда говорят о том, что сервер приложений "общается" с клиентом бизнес-объектами, а с сервером базы — на языке SQL. O> Но при таком подходе получается, что клиент должен как минимум знать о интерфесах бизнес-объектов и, возможно бизнес-классов, которые умеют что-то выполнять с объектами. И изменения в структуре бизнес-объектов ведут к пересборке и обновлению всех клиентов, знающих о этом интерфейсе.
такую проблему позволяет решить использование Веб-сервисов и XML + XSD
... << RSDN@Home 1.2.0 alpha rev. 619>>
Now playing: paul_oakenfold-live_at_sputnik_intesivstation_02-03-2001-cc
Re[2]: Трехзвенка - от клиента до сервера приложений
Здравствуйте, stasukas, Вы писали:
S>Здравствуйте, oleksab, Вы писали:
O>> Обычно при описании трехзвенной архитектуры всегда говорят о том, что сервер приложений "общается" с клиентом бизнес-объектами, а с сервером базы — на языке SQL. O>> Но при таком подходе получается, что клиент должен как минимум знать о интерфесах бизнес-объектов и, возможно бизнес-классов, которые умеют что-то выполнять с объектами. И изменения в структуре бизнес-объектов ведут к пересборке и обновлению всех клиентов, знающих о этом интерфейсе.
S>такую проблему позволяет решить использование Веб-сервисов и XML + XSD
Но вот беда — тогда клиенту надо знать где Веб-сервисы расположены. Выход один — SOA!
Здравствуйте, oleksab, Вы писали:
O> А нет ли каких хитрых путей, позволяющих сделать интерфейсы бизнес-объектов невидимыми для клиента? Так, чтобы клиент при этом получал некий набор простейших типов (string, DateTime, int, double), давал возможность пользователю просмотреть значения, исправить и отправить обратно на сервер? Где уже набор типов будет превращен в бизнес объект, проверен и сохранен в базу (например)?
Гуру корпоративных приложений Мартин Фаулер как раз советует бизнес-объекты на клиент не передавать, а передавать специальный "Data Transfer Object". В общем RTFM
Здравствуйте, oleksab, Вы писали:
O>Добрый день
O> Обычно при описании трехзвенной архитектуры всегда говорят о том, что сервер приложений "общается" с клиентом бизнес-объектами, а с сервером базы — на языке SQL. O> Но при таком подходе получается, что клиент должен как минимум знать о интерфесах бизнес-объектов и, возможно бизнес-классов, которые умеют что-то выполнять с объектами. И изменения в структуре бизнес-объектов ведут к пересборке и обновлению всех клиентов, знающих о этом интерфейсе.
Задача многоуровневых архитектур -- изолировать уровни друг от друга. В трехуровневой архитектуре мы относительно легко можем поменять СУБД (скажем, c Oracle на MSSQL или наоборот) -- нам для этого не нужно переписывать клиента заново. Также, относительно легко мы можем создать новый тип клиента (скажем, у нас уже есть Rich GUI клиент, а мы добавляем Web клиент).
Трехуровневая архитектура подразумевает, что модель предметной области достаточно стабильна, поскольку изменения в ней часто сказываются на всех трех уровнях. Например, если нам надо добавить MiddleName в сущность Person, то нам придется (1) изменить в GUI формы, в которых отображается Person; (2) добавить новый столбец в таблицу Person; (3) изменить DTO, которым Application Server общается с клиентом.
На практике же, необходимость смены СУБД и типа клиента возникает не настолько часто, как изменение в модели предметной области. И здесь, наверное, могут помочь различные tier generator'ы, которые по некоторому абстрактному описанию модели (например, заданной в UML диаграммах) генерят SQL script'ы, DTO, GUI...
O> А нет ли каких хитрых путей, позволяющих сделать интерфейсы бизнес-объектов невидимыми для клиента? Так, чтобы клиент при этом получал некий набор простейших типов (string, DateTime, int, double), давал возможность пользователю просмотреть значения, исправить и отправить обратно на сервер? Где уже набор типов будет превращен в бизнес объект, проверен и сохранен в базу (например)?
O> Имеет ли вообще смысл такой подход?
В общем-то да. Только надо всегда понимать, что ты при этом приобретаешь, а что теряешь.
Здравствуйте, oleksab, Вы писали:
O> Имеет ли вообще смысл такой подход?
Одна из задач слоя является трансформация вида бизнес-объекта в виде в котором их может интерпретировать верхний слой. И так до слоя когда данные интерпретирует человек. Обычно это — реляционная -> объектная -> клиентская форма. В случае трехзвенной еще есть вид который может пересылаться через сеть. А вообще немного неверно разделять понятие бизнес-объекта только как часть объектной логики. Часть бизнес-логики удобно обрабатывать еще на реляционной модели, часть на объектной, а часть при взаимодействии форм с пользователем.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Трехзвенка - от клиента до сервера приложений
Здравствуйте, Mika Soukhov, Вы писали:
O>> Обычно при описании трехзвенной архитектуры всегда говорят о том, что сервер приложений "общается" с клиентом бизнес-объектами, а с сервером базы — на языке SQL. O>> Но при таком подходе получается, что клиент должен как минимум знать о интерфесах бизнес-объектов и, возможно бизнес-классов, которые умеют что-то выполнять с объектами. И изменения в структуре бизнес-объектов ведут к пересборке и обновлению всех клиентов, знающих о этом интерфейсе.
MS>Для устранения данной проблемы используют подход, основанный на толерантности транспортного протокола.
Я "толерантности транспортного протокола" не нашел в сети — дайте ссылок пожалуйста. Или это DTO и есть?
O>> А нет ли каких хитрых путей, позволяющих сделать интерфейсы бизнес-объектов невидимыми для клиента? Так, чтобы клиент при этом получал некий набор простейших типов (string, DateTime, int, double), давал возможность пользователю просмотреть значения, исправить и отправить обратно на сервер? Где уже набор типов будет превращен в бизнес объект, проверен и сохранен в базу (например)?
MS>BO упаковываются в DTO — так клиент общается с промежуточным звеном.
А вот упаковали мы — и что, часть логики (проверка "дата с" меньше "дата по", сумма платежа больше 0 и тд) выносить в уровень DTO? А если проверка намного сложнее и состоит в сложном вычислении, о которых DTO знать как раз не должны? Получается, что нужно будет собрать данные, введенные пользователем обратно в DTO, передать на сервер, там преобразовать в BO, выполнить некие вычисления и или вернуть результат (valid|invalid) или вернуть новый набор DTO, представляющих BO, которые являются результатом вычислений. Как-то кривенько получается :-|
O>> Имеет ли вообще смысл такой подход?
MS>Лучше уж сразу массив байт
Так оно и будет. Где-то между сетевыми картами
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[2]: Трехзвенка - от клиента до сервера приложений
Здравствуйте, GlebZ, Вы писали:
O>> Имеет ли вообще смысл такой подход?
GZ> А вообще немного неверно разделять понятие бизнес-объекта только как часть объектной логики. Часть бизнес-логики удобно обрабатывать еще на реляционной модели, часть на объектной, а часть при взаимодействии форм с пользователем.
При таком подходе получается, что бизнес-логика "размыта" по слоям. А ведь обычно советуют проектировать приложение так, чтобы каждый слой отвечал за что-то свое. И реализация этого чего-то была бы сконцетрирована в одном слое — так мол будет проще и поддерживать, и писать.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[3]: Трехзвенка - от клиента до сервера приложений
Здравствуйте, oleksab, Вы писали:
O> При таком подходе получается, что бизнес-логика "размыта" по слоям. А ведь обычно советуют проектировать приложение так, чтобы каждый слой отвечал за что-то свое. И реализация этого чего-то была бы сконцетрирована в одном слое — так мол будет проще и поддерживать, и писать.
Эх, кто бы мне точно сказал что такое бизнес-логика. Бизнес-логика так и так размыта. Если тебе нужно чтобы поле в html форме содержало именно цифру ты же не будешь ее отправлять на сервер приложений? Точно так же и например если у тебя аггрегируемое значение получаемое из большого количества данных, то лучше эту операцию выполнить на сервере базы данных. То что бизнес-логику можно реализовать только в одном месте — не более чем красивая сказка. Просто над бизнес-логикой начинают понимать определенный слой который только этим и занимается. Есть другое, каждая функциональность имеет определенное место реализации. Хотя это тоже слишком абстрактно. Существует достаточное количество изменений которое можно ввести изменяя только один-два слоя. Это говорит о хорошей реализации. Но если что-то глобальное, то тебе придется и базу тормошить, и сервер приложений и клиентскую часть. Хоть это и возмутительно, оно так есть.
С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Трехзвенка - от клиента до сервера приложений
Здравствуйте, dshe, Вы писали:
D>На практике же, необходимость смены СУБД и типа клиента возникает не настолько часто, как изменение в модели предметной области. И здесь, наверное, могут помочь различные tier generator'ы, которые по некоторому абстрактному описанию модели (например, заданной в UML диаграммах) генерят SQL script'ы, DTO, GUI...
А такие есть?
Re[3]: Трехзвенка - от клиента до сервера приложений
Здравствуйте, oleksab, Вы писали:
O>>> Но при таком подходе получается, что клиент должен как минимум знать о интерфесах бизнес-объектов и, возможно бизнес-классов, которые умеют что-то выполнять с объектами. И изменения в структуре бизнес-объектов ведут к пересборке и обновлению всех клиентов, знающих о этом интерфейсе.
MS>>Для устранения данной проблемы используют подход, основанный на толерантности транспортного протокола.
O> Я "толерантности транспортного протокола" не нашел в сети — дайте ссылок пожалуйста. Или это DTO и есть?
Толерантность протокола обмена данными обеспечивает корректную поддержку версий между сторонами. Как пример ты уже привел, когда обновилось серверное ПО. При этом данные, полученные от устаревших клиентов, должны нормально обрабатываться. На практике, по мимо этой технологии, так же используют технологию автоматического обновления, так как иногда бывает ситуация, что новый формат данных в корне отличается от старых.
MS>>BO упаковываются в DTO — так клиент общается с промежуточным звеном.
O> А вот упаковали мы — и что, часть логики (проверка "дата с" меньше "дата по", сумма платежа больше 0 и тд) выносить в уровень DTO? А если проверка намного сложнее и состоит в сложном вычислении, о которых DTO знать как раз не должны? Получается, что нужно будет собрать данные, введенные пользователем обратно в DTO, передать на сервер, там преобразовать в BO, выполнить некие вычисления и или вернуть результат (valid|invalid) или вернуть новый набор DTO, представляющих BO, которые являются результатом вычислений. Как-то кривенько получается :-|
Простейшие проверки — на клиенте. Простейшие проверки + проверки логические для BE — на сервере. Проверки бизнес логики — на АПП или БД.
Re[3]: Трехзвенка - от клиента до сервера приложений
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, dshe, Вы писали:
D>>На практике же, необходимость смены СУБД и типа клиента возникает не настолько часто, как изменение в модели предметной области. И здесь, наверное, могут помочь различные tier generator'ы, которые по некоторому абстрактному описанию модели (например, заданной в UML диаграммах) генерят SQL script'ы, DTO, GUI...
P>А такие есть?
в сети — дайте ссылок пожалуйста. Или это DTO и есть?
Бизнес-логика так и так размыта. Если тебе нужно чтобы поле в html форме содержало именно цифру ты же не будешь ее отправлять на сервер приложений? Точно так же и например если у тебя аггрегируемое значение получаемое из большого количества данных, то лучше эту операцию выполнить на сервере базы данных. То что бизнес-логику можно реализовать только в одном месте — не более чем красивая сказка. Просто над бизнес-логикой начинают понимать определенный слой который только этим и занимается. Есть другое, каждая функциональность имеет определенное место реализации. Хотя это тоже слишком абстрактно. 
