Как предотвратить использование нескольких классов для одного и того же бизнес-объекта?
Часто у меня будет бизнес-объект, у которого есть свойство для индекса пользователя или набор индексов для некоторых данных. Когда я отображаю этот объект в форме или другом представлении, мне нужно полное имя пользователя или некоторые другие свойства данных. Обычно я создаю другой класс myObjectView или что-то подобное. Как лучше всего справиться с этим делом?
Для дальнейшего уточнения: Если бы у меня был класс, средство отслеживания проблем, и мой класс для проблемы имел бы IxCreatedByUser в качестве свойства и коллекцию значений IxAttachment (индексы для записей вложений). Когда я показываю это на веб-странице, я хочу показать Джона Доу вместо IxCreatedByUser, и я хочу показать ссылку на вложение и имя файла на странице. Поэтому обычно я создаю новый класс с коллекцией объектов вложений и свойством CreatedByUserFullName или чем-то в этом роде. Просто кажется неправильным создавать этот второй класс для отображения данных на странице. Может я ошибаюсь?
Часто сложности невозможно исключить из существования. То, что вы делаете, немного проясняет реальность :-) [en.wikipedia.org/wiki/Facade_pattern]
Ответы 3
Один из ключевых принципов состоит в том, что каждый из ваших классов должен иметь определенную цель. Если целью вашего класса «Бизнес-объект» является предоставление соответствующих данных, связанных с бизнес-объектом, может быть вполне разумным создать свойство в классе, которое делегирует запрос описания поиска соответствующему классу, который за это отвечает. Информация. Любое форматирование, специфичное для вашего класса, будет выполнено в свойстве.
Я думаю, что вы упомянули здесь «Принцип единой ответственности». en.wikipedia.org/wiki/Single_responsibility_principleobjectmentor.com/resources/articles/srp.pdf Я также пишу отдельный класс, который отвечает за форматирование. «MyObjectViewHelper» и т. д.
Рисунок фасада.
Я думаю, что ваш подход, создание шаблона фасада для абстрагирования сложностей с несколькими источниками данных, часто уместен и облегчит понимание вашего кода.
Следует проявлять осторожность, чтобы создать слишком много уровней абстракций, потому что уровень косвенного обращения испортит первоначальную попытку облегчить чтение кода. Особенно, если вы чувствуете, что просто пишете классы в соответствии с тем, что вы делали в других местах. Например, если у вас есть myLoanView, вам не обязательно создавать myView для каждого отдельного диалога в системе. Отойдите на 10 шагов от кода и, возможно, сделайте фасад, который представляет собой многоразовую и интуитивно понятную абстракцию, которую можно использовать в нескольких местах.
Не стесняйтесь подробно описывать суть вашей задачи.
Вот несколько рекомендаций, которые помогут вам решить, как справиться с этим (довольно распространенным, IMO) шаблоном:
Если вам нужна всего лишь быстрая ссылка на таблицу поиска, которая не часто меняется (например, таблица адресов, которая ссылается на таблицу состояний и / или стран), вы можете сохранить статическую копию поиска с отложенной загрузкой. стол.
Если у вас действительно большой класс, который требует загрузки множества соединений или подзапросов только для целей отображения, вы, вероятно, захотите создать класс «представление» или «информация» для целей отображения, как вы описали выше. Просто убедитесь, что класс XInfo (для отображения) загружается значительно быстрее, чем класс X (для редактирования). Это ситуация, когда использование представления на стороне базы данных может быть очень хорошей идеей.
Не могу понять, чего вы хотите.