#c# #asp.net #.net #wpf #asp.net-web-api
#c# #asp.net #.net #wpf #asp.net-web-api
Вопрос:
Я создаю некоторое программное обеспечение, в котором есть настольное приложение WPF, написанное на C # .NET, и некоторое локально сохраняемое хранилище с использованием базы данных SQLite.
Я также создал базу данных SQL Server, размещенную в Azure, для сохранения данных в облаке, и я работаю над веб-API ASP.NETCore, который будет находиться между базой данных и любыми клиентами, желающими сохранить данные на сервере.
В процессе я понял, что куча кода, такого как мое подключение к базе данных и помощники (или, по крайней мере, их интерфейсы), а также интерфейсы модели, которые определяют, какие свойства определенного объекта (например, финансовая транзакция) могут использоваться совместно и повторно как в настольном приложении, так и в веб-API.
В будущем я планирую создать мобильные приложения, и они, несомненно, снова будут использовать большую часть той же логики и кода DAL. Итак, мой вопрос: каков наилучший способ спроектировать архитектуру, чтобы быть готовым к будущему сейчас и избежать многократной переразложения моего кода?
Мой план прямо сейчас состоит в том, чтобы создать API (библиотеку классов), которая будет содержать бизнес-логику, DAL и модель данных, и чтобы на этот API ссылалось настольное приложение (которое затем становится просто облегченным слоем пользовательского интерфейса с использованием MVVM) и ссылки контроллерами веб-API. У меня была бы одна реализация внутри API, предназначенная для взаимодействия с SQLite, а другая — с SQL Server.
Проблема / путаница, которую я вижу, заключается в том, что в конечном итоге у меня будет библиотека классов на моем настольном клиенте, которая сохраняет некоторые данные локально, но она также вызывает веб-API для сохранения данных, который затем вызывает ту же библиотеку классов, только сохраненную на сервере, чтобы сообщить DAL выполнить некоторые действия.операции с базой данных сервера.
Что-то кажется … неправильным в этой настройке. Я пытаюсь упростить вещи и повысить удобство обслуживания, но, похоже, вместо этого я все усложняю. Я что-то упускаю?
Чем больше я читаю, тем больше кажется, что есть 10 способов сделать что-либо, и мне не совсем ясно, какой способ лучше.
Спасибо!
Комментарии:
1. Почему бы не заставить оба решения взаимодействовать с одним веб-сервисом для сохранения?
2. Я хочу сохранить данные локально, чтобы пользователи могли продолжать использовать настольное приложение в автономном режиме, и в этом случае клиент будет синхронизировать изменения с сервером, когда он сможет повторно подключиться.
3. Хорошо, так что сделайте это и используйте общий API при синхронизации
4. Но логика сохранения и запроса локальной базы данных от клиента почти идентична логике Web API по отношению к серверной, поэтому я подумал, что мне следует повторно использовать этот код?
5. Похоже, для этого тоже нужен функциональный подход — если вы хотите сохранить изменения локально для пользователя, но позже проверить и применить бизнес-логику, вам нужно использовать асинхронность: сделайте самую наивную вещь, которую вы можете локально, а затем обработайте несоответствия, когда данные в конечном итоге отправляются на сервер. Когда вы это сделаете, логика для обоих, вероятно, будет совершенно разной.