Абстрагирование уровней подключения к данным и уровней представления в корпоративном приложении
Мы создаем корпоративное приложение, в которое мы будем включать несколько платформ для пользовательских интерфейсов (например, ASP.net webapp, приложение Windows и, когда-нибудь, мобильные приложения) и несколько платформ для внутренних баз данных (например, SQL Server, XML, Oracle). Дополнительная необходимость заключается в том, чтобы эти внутренние БД были либо централизованы и доступны через Интернет, либо локализованы на клиентском компьютере и иногда синхронизируются с центральным сервером.
Может ли кто-нибудь дать совет о том, как мы можем абстрагироваться от уровня пользовательского интерфейса и уровня данных, чтобы мы могли более просто создать адаптивность plug-and-play между различными пользовательскими интерфейсами и различными вариантами для БД? Например: в одном случае у нас может быть веб-приложение, работающее на централизованном сервере через Интернет, и у нас могут быть удаленные машины, на которых выполняются локализованные копии через приложение Windows. Через определенные промежутки времени мы хотели бы, чтобы все машины синхронизировались, чтобы все они могли иметь данные, близкие к реальному времени.
Нам также нужен совет по обработке различных задействованных строк подключения, чтобы единственный параметр, который нужно было изменить в любом приложении, был «локальным» или «удаленным», который затем определил бы необходимую строку подключения.
Ответы 2
Я бы посмотрел на использование модели поставщика для установления соединений с базой данных в вашем приложении.
Я бы начал с рассмотрения примеров и подробностей, представленных в блоке приложений данных Microsoft, я думаю, что это поможет вам в этом частично.
Абстрагирование уровня представления - довольно простая концепция, если вы уже знакомы с многоуровневой архитектурой. Просто сосредоточьтесь на различении «логики предметной области» от «логики приложения». Логика домена является общей для разных платформ, а логика приложения зависит от платформы. Например, проверка данных - это логика домена (хотя приятно, когда вы можете делать это во внешнем интерфейсе, что усложняет задачу, но работайте со мной здесь ...), а решение, на какой URL-адрес перенаправлять после некоторого действия, - это приложение логика. Убедитесь, что вы разместили логику домена на уровне, пригодном для использования на любой платформе, и убедитесь, что логика приложения не помещена на уровень домена.
Другая половина вашего вопроса кажется вам более важной, но я хотел бы попросить здесь некоторых пояснений, поскольку я могу выделить два разных важных вопроса.
Я надеюсь, что вы не стремитесь к «святому Граалю» независимости баз данных. Это всегда высокая цель, к которой стремятся на этапе проектирования, которая почти всегда, почти каждый раз не нужна.
Если это не то, к чему вы стремитесь, я бы посоветовал вам знать, какие объекты хранятся в какой среде сохранения, и вам следует избегать сложности гибкости и просто кодировать свои вертикальные пути как можно более прямолинейно. насколько возможно. IE не кодирует лишний материал в каком-то бизнес-классе, который хранит свои данные в Oracle, чтобы вы могли поместить их в SQL Server «в какой-то момент в будущем». (Я вернулся к независимости базы данных циклически, не так ли?)
Вопрос о локальном кэшировании данных для повышения производительности для определенных платформ специфичен для этих платформ, и я предлагаю вам изучить Smart Clients и структуру / руководство кэширования, которое есть у команды MS P&P. Последние пару лет я работал исключительно над веб-материалами, но в 05/06 это было довольно хорошо, а тем временем они много работали над своими интеллектуальными клиентами.