передача данных в более приложение

Question

Как вы передаете данные в слои в n-уровневом приложении? Я наметил 3 разных метода.

A) универсальные .net объекты универсальные таблицы данных, Hashtables, универсальные наборы данных, строки, целые и т. д. затем используйте наборы данных для заполнения ваших бизнес-объектов, которые отправляются на уровень пользовательского интерфейса.

альтернативный текст http://img11.imageshack.us/img11/460/generic.png

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

Pro- Никаких дополнительных слоев не требуется Con- Необходимо работать с универсальными наборами данных и таблицами на бизнес-уровне

B) используя слой сущностей, на который ссылаются другие слои. Этот слой будет содержать либо строго типизированные наборы данных, либо Plain Old C Objects. Объектами будут в основном данные контейнера и очень мало логики. это будут те же самые объекты, отправленные на уровень пользовательского интерфейса.

альтернативный текст http://img8.imageshack.us/img8/6454/entities.png

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

Pro- работа с одинаковыми классами во всех слоях Con- добавление ссылки на entity.dll ко всем слоям

C) использовать объекты передачи данных (только объекты conatiner), определенные на уровне DataAccess. затем использовать эти объекты для заполнения бизнес-объектов, которые отправляются на уровень пользовательского интерфейса.

альтернативный текст http://img43.imageshack.us/img43/1236/transferp.png

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cdcdaec0a9b

Pro- бизнес-уровень не должен работать с общими классами Con- работает с двумя типами объектов, и вам придется гидрировать бизнес-объекты с помощью объектов переноса

Мы провели обсуждение на работе и хотели посмотреть, что думает сообщество. Я также добавил ссылку на доску объявлений. пожалуйста, скопируйте и создайте вместо редактирования.
Спасибо

Answer 1

Если вы используете многоуровневый подход , означающий, что все слои (по существу) выполняются в одном и том же пространстве процесса и поэтому нет маршалинга / сериализации, я бы пошел с подходом B. отдельный модуль для ваших сущностей, от которого зависят все аспекты вашей программы, и привязайтесь к нему.

Если, однако, вы используете многоуровневый подход, как следует из названия, то есть пересекаются границы процессов и / или сетей, я бы предложил вам перейти к подходу C. Вы ' на самом деле вы не передаете экземпляры, вы передаете копии, поэтому любые преимущества, которые вы получаете при соединении с одним и тем же объектом, такие как наблюдаемые варианты, скажем, подхода MVC, все равно теряются. Лучше определять API данных на каждом уровне, чем пытаться использовать один и тот же класс.

Answer 2

Отличный вопрос - как всегда, ответ должен быть "это зависит".

О типе приложения и о том, действительно ли необходимо иметь бизнес-объекты (сущности), а не объекты переноса (то есть неработающие бизнес-объекты, которые больше соответствуют сущностям базы данных).

Традиционно я бы сказал, что вам всегда нужны универсальные наборы данных (или таблицы данных), исключительно из соображений производительности. Всякий раз, когда возникает необходимость работать, отображать или манипулировать большими наборами, традиционный строгий OO-способ создания большого количества бизнес-объектов не удался.

Однако с тех пор, как я начал работать с Linq to SQL, мои парадигмы изменились. Больше нет необходимости в этом, поскольку модель Linq может быть всем: бизнес-объектами, объектами переноса и общими наборами данных. Я еще не исследовал, насколько хорошо это работает в действительно больших приложениях и должна ли быть необходимость изолировать интерфейсный код от модели Linq. Я обсуждал это с коллегами, но так или иначе не нашел ответа.

Answer 3

Я предполагаю, что все 3 слоя существуют в одном приложении. В версии Java, по крайней мере, я использовал Hibernate для доступа к данным и использовал эти компоненты данных на всех уровнях. (вариант B) Имеет смысл иметь возможность повторно использовать ваши сущности в ваших слоях.

Answer 4

Мне нравится вариант C, но он также дает мне паузу по двум причинам:

1. Я должен распространить знания о том, что есть в слишком многих местах.
2. DTO должны быть сериализуемыми, что не так уж и страшно, но все же необходимо учитывать.