ООП - Куда поместить вызовы в Уровень доступа к данным?
Проблема кажется логичной, поскольку вы создаете свой список показа ( Показывает ) в конструкторе, каждый раз, когда вы создаете Фильм новый список показа ( Показывает ) будет создан.
В вашем случае вы должны использовать шаблон синглтона
Шаблон синглтона - это шаблон проектирования Creation, который гарантирует один экземпляр объекта. [113 ]
private static List<Show> shows; public static List<Show> Shows { get { if (shows == null) { shows = new List<Show>(); } return shows; } }
3 ответа
Я соглашаюсь, что вызовы данных не принадлежат уровня UI. Это для презентации только.
Я думаю, что они правильно принадлежат уровня служб. Реализация услуги использует объекты модели и слой персистентности для выполнения его целей. Является ли это основанным на XML веб-сервисом или локальным интерфейсом, сервис является объектом, который отображается на варианты использования и знает о единицах работы.
Или поместите вызовы базы данных в отдельный слой персистентности или встройте их в объекты модели для дополнительной объектно-ориентированной чистоты.
Чем меньше Вашего приложения знает о Вашем DAL, тем лучше. Существует несколько способов сделать это, и я думаю, что Вы на правильном пути. Я думаю, что Вы могли бы хотеть изучить шаблон "фабрика" для этой реализации, поскольку Вы сможете скрыть реализацию DAL позади фабрики и объектов возврата и наборов объектов от фабрики.
Причина, почему Вы хотели бы вытянуть операции CRUD в отдельный слой, состоит в том в случае, если Вы когда-нибудь хотите изменить системы баз данных. Ну, вот почему я сделал это. Я не рекомендовал бы делать это только, чтобы быть хорошим OOD. Но здесь Вы идете...
Несколько наборов классов/интерфейсов
BusinessObject - Представляет бизнес-объекты типа, такие как Клиент, имеет DataManager как свойство.
DataManager - Возможно, можно придумать лучшее имя, но эта вещь обеспечивает Загрузку (), и Сохраните () функции для BusinessObjects
SearchList - Списки возвратов вещей, Ваши SQL-запросы идут сюда. Также это должно, вероятно, вести себя как RecordSet со Следующим (), Eof (), и CurrentRecord вводят участников
Конструктор/Фабрика - Видит FactoryPattern. Вы отделили свои операции базы данных от Ваших бизнес-объектов, эта вещь повторно связывает их необходимым способом. Присваивает соответствующую datamanager реализацию BusinessObject
Придуманный безотносительно подлинных имен Вы хотите, но давайте говорить о Клиенте снова. Предположим, что у Вас есть база данных Oracle. Вы могли бы закончить с этими классами:
boCustomer, который наследовался BusinessObject
oracleDMCustomer, который наследовал или реализует DataManager
searchlistCustomer, который наследовался searchlist, который выставил или через абстрактные методы или как интерфейс что-то как:
- SearchAll () - который должен возвратить всего клиента
- SearchByZip (Строковая zip), который должен возвратить всех клиентов с данным индексом
oracleSearchlistCustomer - реализует searchlistCustomer, на самом деле реализовал бы SearchAll () и SearchByZip ()
boFactory - статический класс, который имеет метод, который смотрит что-то как CreateObject (Вводят тип),
searchlistFactory - статический класс, который имеет метод, который смотрит что-то как CreateSearchList (Вводят тип);
Я позволю Вам заполнить некоторые пробелы, но я думаю, что важный материал там. У других могут быть различные идеи, которые требуют меньшего количества абстракции. Я копировал бы несколько стратегий прежде, чем идти с одной.