Здравствуйте! Есть небольшая база данных, допустим, библиотеки. Какие паттерны проектирования стоило бы использовать? Какие правила стоит учитывать при проектировании базы данных и самого приложения? Стоит ли использовать паттерн MVP и какая выгода будет от этого? Заранее спасибо.
Ответ
Как сказали в уточнениях, паттерн MVP действительно не имеет отношение к БД. Он скорее имеет отношение к интерфейсной части (client-side). Я бы сказал, что самое главное правило, которого стоит придерживаться при разработке приложений, которые обращаются к БД, это трехслойная архитектура: UI - Business Logic - DB. В самом тупом случае, слой DB у вас может представлять собой набор хелперов для работы с БД. В частности, отмечу некоторые важные моменты: все прямые обращения к БД должны быть только в слое DB, никаких прямых вызовов к БД, разбросанных по всему коду все обращения к слою DB должны исходить только из слоя BL, в UI не должно быть прямых вызовов кода из слоя DB В остальном, реально не имеет значения (особенно в небольшом проекте), как у вас будет организовано получение и сохранение данных: тупые датасеты, ORM или что-то еще. Существует несколько распространенных паттернов для работы с данными, однако их применение также не очень критично (и уж точно не стоит применять их ради самого факта применения, о чем говорили выше). Главное — обособить код для работы с базой, это уже избавит вас от множества проблем. Ниже список некоторых паттернов для работы с БД: http://design-pattern.ru/patterns/repository.html http://ru.wikipedia.org/wiki/Data_Access_Object http://design-pattern.ru/patterns/table-data-gateway.html http://design-pattern.ru/patterns/row-data-gateway.html http://design-pattern.ru/patterns/active-record.html -- тут я готов спорить, предпочитаю иметь тупые объекты (DTO, только данные) плюс классы, которые отвечают за загрузку/сохранение http://design-pattern.ru/patterns/data-mapper.html
Комментариев нет:
Отправить комментарий