Добрый день,
Думаю, что ситуация достаточно стандартная, но не знаю как найти ответ в гугле.
Самостоятельное (основное) приложение клиента = GUI + бизнес-логика.
Отдельная библиотека связи с БД (не важно через сервер или напрямую).
В основном приложении нужны бизнес-объекты, данные которых подлежат сохранению в БД. Библиотека БД должна обеспечить это сохранение, при этом основное приложение не должно знать как именно и с какой именно БД осуществляется взаимодействие.
Соответственно, что видится. Сборка основного приложения. Сборка интерфейса описывающего данные бизнес-объектов и методы сохранения/чтения их из БД. Сборка библиотеки взаимодействия с БД.
На первый взгляд все кажется хорошо. Но бизнес объектам хорошо бы реализовать методы, например верификации, сохранения, синхронизации... Реализовывать ту же верификацию должно основное приложение и знать об это реализации библиотеки БД совершенно ни к чему. Но при этом конструктор бизнес-объектов должен быть доступен и основному приложению, и библиотеке БД. Основному приложению, например, чтобы создавать новый бизнес-объект, который после заполнения данными из GUI подлежит сохранению в БД. Библиотеке БД, чтобы создавать множество бизнес-объектов по запросу в БД, чтобы впоследствии основное получение, получив это множество, могло отобразить, например, в гриде.
Соответственно возникает вопрос — где и как необходимо реализовывать класс наследующий интерфейс бизнес-объектов, чтобы все вышеописанное реализовать. При этом как основное приложение, так и библиотека, должны быть взаимонезависимы. Чтобы, при необходимости, библиотеку можно было заменить на другую, просто заменив dll без пересборки основного приложения.
Здравствуйте, CyberRussia, Вы писали:
CR>Добрый день, CR>Думаю, что ситуация достаточно стандартная, но не знаю как найти ответ в гугле. CR>Самостоятельное (основное) приложение клиента = GUI + бизнес-логика. CR>Отдельная библиотека связи с БД (не важно через сервер или напрямую). CR>В основном приложении нужны бизнес-объекты, данные которых подлежат сохранению в БД. Библиотека БД должна обеспечить это сохранение, при этом основное приложение не должно знать как именно и с какой именно БД осуществляется взаимодействие. CR>Соответственно, что видится. Сборка основного приложения. Сборка интерфейса описывающего данные бизнес-объектов и методы сохранения/чтения их из БД. Сборка библиотеки взаимодействия с БД. CR>На первый взгляд все кажется хорошо. Но бизнес объектам хорошо бы реализовать методы, например верификации, сохранения, синхронизации... Реализовывать ту же верификацию должно основное приложение и знать об это реализации библиотеки БД совершенно ни к чему. Но при этом конструктор бизнес-объектов должен быть доступен и основному приложению, и библиотеке БД. Основному приложению, например, чтобы создавать новый бизнес-объект, который после заполнения данными из GUI подлежит сохранению в БД. Библиотеке БД, чтобы создавать множество бизнес-объектов по запросу в БД, чтобы впоследствии основное получение, получив это множество, могло отобразить, например, в гриде. CR>Соответственно возникает вопрос — где и как необходимо реализовывать класс наследующий интерфейс бизнес-объектов, чтобы все вышеописанное реализовать. При этом как основное приложение, так и библиотека, должны быть взаимонезависимы. Чтобы, при необходимости, библиотеку можно было заменить на другую, просто заменив dll без пересборки основного приложения.
В 2020-м не надо бизнес объектам интерфейс.
До популяризации такого понятия как миграции делали интерфейс в слое доступа к данным. и делали несколько реализаций этого интерфейса.
После — либо миграции независимы и от логики и от доступа к данным. Например для SQLITE, MySQL и SQL Server свои миграции. Либо миграции идут как часть библиотеки доступа к данным. в зависимости от сложности и в том числе необходимости машстабирования процесса разработки.
Re[2]: Бизнес-объекты при независимой библиотеке БД
Здравствуйте, VladCore, Вы писали: VC>В 2020-м не надо бизнес объектам интерфейс.
Не все еще на 2020 перешли.
VC>До популяризации такого понятия как миграции делали интерфейс в слое доступа к данным. и делали несколько реализаций этого интерфейса.
Вот тут можно подробнее? Или ссылку, где подробнее прочитать. Потому что если разные реализации в основном приложении и в библиотеке бд, то я не улавливаю, как к объектам созданным в библиотеке БД основное приложение проведет верификацию данных.
VC>После — либо миграции независимы и от логики и от доступа к данным. Например для SQLITE, MySQL и SQL Server свои миграции. Либо миграции идут как часть библиотеки доступа к данным. в зависимости от сложности и в том числе необходимости машстабирования процесса разработки.
Миграции, насколько я понимаю, это изменение базы данных от изменения модели данных. Это уже не то, что интересно. Тем более, что до самой БД может быть еще достаточно далеко и несколько сервисов посредников.
Тут напрашивается DDD (Domain Driven Design)
Поищите на хабре по DDD и там вам накидает.
Сейчас колбасят приблизительно так, поправьте меня коллеги.
UI -> DTO(Data Transfer Object) -> BusinessEntity(DomainModel) -> BusinessLogic with IRepository<BusinessEntity> + IUnitOfWork -> Database (IUnitOfWork + IRepository implementation).
Схематически это не изменяется
BusinessModule - Domain
BusinessEntities,
BusinessServices,
Validation,
IRepository1, ..., IRepositoryN, -- так повелось что тут как правило Generic Repository
IUnitOfWork
Здравствуйте, Danchik, Вы писали: D>Тут напрашивается DDD (Domain Driven Design) D>Поищите на хабре по DDD и там вам накидает.
Спасибо — посмотрю
CR>>Отдельная библиотека связи с БД (не важно через сервер или напрямую). D>А вот это может быть важно. IQueryable тут тогда сильно не поиспользуешь.
Основное приложение должно быть независимым от того, что по другую сторону библиотеки БД. И вполне там может оказаться сервер, или даже несколько параллельных.
Re[2]: Бизнес-объекты при независимой библиотеке БД
