Приложения баз данных. Паттерны проектирования.

#c_sharp #шаблоны_проектирования #sql_server

Здравствуйте! Есть небольшая база данных, допустим, библиотеки. Какие паттерны проектирования
стоило бы использовать? Какие правила стоит учитывать при проектировании базы данных
и самого приложения? Стоит ли использовать паттерн MVP и какая выгода будет от этого?
Заранее спасибо.    

Ответы

Ответ 1

Как сказали в уточнениях, паттерн 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