Несколько приложений и общая БД. Направьте в правильную сторону

Всем доброго дня!

Есть несколько приложений использующие общую Базу Данных.
Раньше делал сервисы по работе с этой бд в отдельную библиотеку, и все приложения через эту библиотеку работали с одной БД. (на форуме задавал вопросы по этому поводу, кому интересно посмотрите в моих темах).

Но сейчас вопрос вот такой.
Как вообще правильнее это сделать?

Я так понимаю, нужно сервисы с базой данных создать в отдельном приложении API?

Допустим я создаю ASP NET API приложение (допустим MyAPI), и всю работу переношу туда.

То теперь всем приложениям нужно добавлять работу с API сервисом через http протокол?

Из плюсов вижу, что одно приложение будет только работать с БД, и всё.

А вот из минусов нужно создавать полностью работу с api, с учётом того, что API может быть недоступен и т.д.
То есть кода будет намного больше.
Постоянно нужно будет преобразовывать объекты в json и наоборот, что увеличит нагрузку на пк.
Дополнительные настройки для API подключения в самих приложениях-клиентах.

А так же нужно как-то следить за тем, что сервис MyAPI будет запущен.



В статьях и видео, вижу только сам факт создания API.
Если это просто отдельный сервис, то понятно, а вот в связке со своим приложением нигде примеров не видел.


Объясните на сколько это вообще правильная идея?
И как в таком случае обновлять обновлять приложение-сервер API MyAPI?

0

Сообщение от BeginnerCoderCS Допустим одно приложение регистрирует пользователей в БД, другое выгружает статистику этих данных и т.д.

Эпическая херня. Сори, но по другому я назвать это не могу. Это как вместо заменить сверло -- покупать новую дрель.

У меня всё больше ощущение что вам на самом деле нужно просто написать одно нормальное клиент-серверное приложение и все ваши вопросы "магическим" способом решатся.

0

Сообщение от Wolfdp Эпическая херня

Так а почему нет? Есть какая-то [наследная] база, к ней есть какой-то API для какого-то десктопного клиента. Потом возникают какие-то мелкие задачи по интеграции (в обе стороны) с другими сервисами, под каждую из которых реализуется свой маленький сервис с одним-двумя методами. Далее, надоедает права напрямую в базе править, реализуется отдельным сервисом API управления правами и к нему отдельный десктопный (и/или веб) клиент (админка, по сути).

Вроде, вполне обычная ситуация. Ну не пихать же вообще весь API в один сервис. Да и часть логики самого десктопного приложения вполне может обособляться в полноценные отдельные приложения (как декстопные, так и веб), реализованные поверх той же БД (или группы БД), но со своими API и своими клиентами.

0

Сообщение от Wolfdp любая виртуализация конфликтует между собой.

Именно поэтому, но я и не спрашивал, а написал утвердительно.
Ну и вообще docker для линукса, и не фиг его в win городить ))

Сообщение от Wolfdp Эпическая херня. Сори, но по другому я назвать это не могу. Это как вместо заменить сверло -- покупать новую дрель.

Странно конечно, но не вижу связи с заменой сверла и дрелью.
Если так, то по вашему мнению Excel, Word, Photoshop и т.д. должны быть не отдельными приложениями а одним общим клиент-серверным?
Ведь есть у меня папка с картинками (БД), из которой я вставляю сообщения в Excel и Word, и открываю для редактирования эти же картинки в Photoshop.

0

Сообщение от kotelok Так а почему нет?

У меня стойкое ощущение что там проект на полсотни методов для api и с полдюжины форм. Грубо говоря -- не шибко большой, чтобы его распылять на отдельные. Плюс пользователи общие, т.е. можно регаться в каждом приложении под одной учеткой. Из этого делаю вывод что проще и правильнее будет сначала сделать добротный вменяемый монолит, и уже поняв на практике где есть смысл выносить в отдельные решения.

Честно говоря всё это -- обсуждение коня в вакуме. Есть задачи, когда монолит будет в тему. Есть задачи когда таки стоит даже без практически полученого фидбека заранее разнести по разным приложениям. Более того: что такое "разное приложение"? Тот же web api имеет такую шляпу как area. Какой-нибудь WPF клиент можно организовать так, что будут (не) подгружаться модули в зависимости от роли юзера. Технически всё это монолит, но построение модульное и упрощает в некоторой степени жизнь.

Добавлено через 20 минут

Сообщение от BeginnerCoderCS Если так, то по вашему мнению Excel, Word, Photoshop и т.д. должны быть не отдельными приложениями а одним общим клиент-серверным?

Вот вам противоположный пример -- VisualStudio. На заре для free-редакций было разделение отельное приложение под desctop C#, отдельное под web и т.д. Сейчас всё слито воедино, оставив модули. Причем 99% не юзает и половины возможностей студии, например тот же git. Либо outlook -- календарь + почта. Можно и отдельно, но это два модуля, которые на работе юзают вместе в 99 случаев из 100.

Если говорить про серверную часть: там разделение/монолит может быть обусловленно 100500 причинами, все я их не опишу. Причем может быть ситуация когда для одного клиентского приложения подымается либо несколько копий (кластеризация) серверного приложения, либо разбивается на несколько серверных модулей, каждый из которых строго заточен под конкретную задачу (допустим есть api на asp.net core, но также статика выкинута вообще отдельным решением. По факту -- два сервака).

Из личного опыта: разделить монолит на несколько частей проще, чем объединять разные сервера общей логикой. Например вам придется кешировать данные. В рамках одного процесса это делается элементарно и надежно, в отличии от двух разных, которые ещё могут и физически быть разнесены очень далеко.

Исходя из этого, плюс тот факт что у вас очень "тривиальный вопросы" (что на водят на мысль неправильности некоторых решений) -- я предлагаю найболее щадящий подход "просто написать грамотное клиент-серверное приложение", который в дальнейшем принесет меньше боли и дает возможности сопровождения. Без детального вникания в вопрос "что это за приложения" -- я большего посоветовать не могу.

0