Передается ли объект модели предметной области между слоями?

Question

Я работаю над проектом, который использует спящий и весенний. Hibernate инкапсулирован в уровне DAO, а уровень DAO также имеет соответствующий уровень обслуживания, а также контроллеры, которые отображаются для запросов и страниц JSP. Мне сказали не передавать объекты между этими слоями (Controllers <-> Service <-> DAO), так как это приводит к снижению производительности. Один конкретный случай произошел, когда мне нужно было обновить логическое значение в объекте домена (класс ORM), я написал метод, который передавал объект домена между уровнем службы и уровнем DAO, и мне сказали передать идентификатор объекта и конкретное логическое значение значение только и написать отдельные методы в слоях для этого. Это правильно? Я чувствую, что это сделает недействительными многие преимущества использования инструмента ORM (Hibernate). Я ошибаюсь, чтобы думать это? Любые советы и идеи будут полезны ....

Answer 1

Ты на 100% прав. Это ужасный совет. Передайте объекты вокруг. Это именно то, для чего предназначен Hibernate, а «накладные расходы» на обычную передачу объектов просто сумасшедшие. Если в приложении есть что-то, чего вы не знаете, остерегайтесь совета от человека, который вам это сказал.

Answer 2

преждевременная оптимизация - корень всего зла

Даже в высокочастотной торговле, где 50 наносекунд имеют значение, вы сначала делаете то, что правильно, а , а затем оптимизируете, если это необходимо. Вы будете удивлены, что могут сделать современные компиляторы / пропускная способность сети.

Чтобы ответить на ваш вопрос более прямо => передать эти объекты и не думать о производительности. Вы будете, если вам нужно позже, но это весьма маловероятно, что это будет вызвано передачей Объектов вокруг.

Answer 3

Как и в случае большинства архитектурных проблем, здесь необходимо найти компромисс.

Для приложений, которые не предполагают использовать сервис-ориентированную архитектуру (например, автономный веб-сайт с резервной базой данных, единое внутреннее бизнес-приложение), гораздо лучше представить модель вашего домена на всех уровнях приложения. , Это гарантирует, что вы не нарушите принцип «СУХОЙ» («Не повторяйте себя»), и вам не придется много заниматься рефакторингом каждый раз, когда вы добавляете новое свойство в модель вашего домена. Вы также можете использовать такую ​​среду, как NHibernate Validator, чтобы определить всю свою проверку один раз, и использовать эту проверку как для уровня данных, так и для веб-уровня.

Для более крупных приложений, которые содержат много отдельных служб (например, большие наборы внутренних бизнес-приложений), желательно отделить ORM от интерфейса службы. Это позволит вам вносить изменения в модели доступа к данным без изменения интерфейса службы (и наоборот), что чрезвычайно важно, когда многие другие службы зависят от стабильности вашего интерфейса.

Однако описанная вами ситуация (использование методов для изменения определенных свойств), по-видимому, не соответствует ни одному из этих сценариев: как правило, плохая идея следовать описанному шаблону, так как отслеживание путей выполнения и рефакторинг сложно (и может привести к спагетти-коду). Единственное возможное использование, о котором я могу подумать, - это если ваши модели данных очень большие (5 тыс. Блобов XML и т. Д.), И отправка их через уровень обслуживания будет генерировать большие объемы трафика. (Примечание: объекты C # намного меньше 5k при правильной сериализации!)

Я бы порекомендовал передать всю модель доступа к данным на веб-слой.