Бизнес-объект: частный экземпляр VS один экземпляр - PullRequest
1 голос
/ 17 марта 2010

Предположим, что мое WinForms приложение имеет бизнес-сущность Order, сущность используется в нескольких представлениях, каждое представление обрабатывает свой домен или сценарий использования в приложении. Например, один управляет заказами, другой копается в одном заказе и отображает дополнительные данные.

Если бы я использовал nHibernate (или любой другой ORM) и использовал один сеанс / dataContext для представления (или для действия в дБ), я бы в итоге получил два разных экземпляра для одного и того же Order (скажем, orderId = 1) , Хотя функционально это один и тот же объект, технически это два разных экземпляра. Да, я мог бы реализовать Equals / GetHashcode, чтобы они «казались» одинаковыми.

Зачем вам использовать один экземпляр для сущности по сравнению с частными экземплярами для представления или варианта использования?

Преимущество наличия единичных экземпляров заключается в совместном использовании событий INotifyPropertyChanged и совместном использовании дополнительных (непостоянных) данных.

Наличие частного экземпляра в каждом представлении даст вам гибкость функциональности отмены на уровне представления. В приведенном выше примере я позволил бы пользователю изменять детали заказа и предоставил им возможность не сохранять изменения. Здесь синхронизация между представлением / вариантом использования происходит на уровне постоянства данных.

Каким будет ваш аргумент?

Ответы [ 2 ]

2 голосов
/ 17 марта 2010

Вы должны реализовать Equals / GetHashCode методы. Это рекомендуемая практика при использовании ORM.

Кроме того, вы обычно должны придерживаться «Один взгляд, один сеанс» мантры. Сохраняйте все свои объекты, когда ваш вид изменится или потеряет фокус. Если вам действительно нужно обмениваться сущностями между видами ... ну сделайте это! Иногда вам нужно.

И снова, потому что, когда мы смотрим на бизнес-объекты с точки зрения сущности и типа строки, мы не должны беспокоиться о равенстве на уровне «объекта».

0 голосов
/ 17 марта 2010

Я не могу говорить за ORM, но я думаю, что вы ответили на свой вопрос - в какой-то степени. Вы предоставили плюсы и минусы для обоих вариантов: ни один не является правильным или неправильным в абсолютном выражении.

Варианты только правильные или неправильные в зависимости от вашей ситуации. Если обмен информацией имеет смысл, используйте единый общий экземпляр, но если возможность отмены важнее, используйте несколько частных экземпляров.

У вас могут быть и другие проблемы, которые также влияют на принятие решений: подумайте о NFR (или «болезнях») и контексте системы. Например, если производительность является ключевой проблемой, и вы знаете, что у вас будут большие пользовательские базы, это может помочь предложить один вариант над другим или заставить вас переосмыслить его с нуля.

Наконец - у вас есть «порядок», а как насчет других объектов - как они обрабатываются?
Или, если у вас их нет, что произойдет, если / если вы это сделаете? Будет ли это иметь какое-либо представление о вашей архитектуре?

...