Иногда подключенное приложение CRUD DAL

Question

Я работаю над приложением CRUD «Иногда подключено», которое в основном будет использоваться группами (2–4) социальных работников и медсестер для отслеживания информации о пациентах в форме плана.Это приложение представляет собой обновленную версию приложения ASP.Net, созданного до меня.В 4 базах данных имеется около 200 таблиц.Версия веб-приложения в значительной степени опиралась на SP, но поскольку эта версия представляет собой приложение Winform, которое будет указывать на локальную базу данных, я не вижу причин продолжать использовать SP.Также следует отметить, что я планировал использовать репликацию слиянием для обработки части синхронизации, и, похоже, с этими двумя вместе возникли некоторые проблемы.

Я пытаюсь понять, какой подход использовать для DAL.Изначально я планировал использовать LINQ to SQL, но прочитал пикантную информацию о том, что он не работает в настройке «Иногда подключается».Поэтому я пытался прочитать и поэкспериментировать с многочисленными решениями;SubSonic, NHibernate, Entity Framework.Это относительно простое применение, и из -за «надвигающегося» перепроектирования Verion 3 это усилие может быть пограничено «переброшением». Акцент здесь делается на получение настольной версии и запуска как можно скорее.

Я прошу всех, у кого есть опыт использования любой из этих технологий (или тех, которые я не перечислил), поделиться со мной своей с трудом заработанной мудростью.Каков, по вашему мнению, мой лучший подход?Есть ли еще идеи по созданию такого рода приложений?Я действительно борюсь с частью DAL этой программы.

Спасибо!

Answer 1

Если хранимые процедуры делают то, что вы от них хотите, я бы сказал, что сомневаюсь, что вы получите выгоду, отбросив их и переопределив.Более того, не имеет значения, используете ли вы хранимые процедуры или доступ к данным в стиле LINQ to SQL, когда приходит время реплицировать ваши данные обратно в главную базу данных, поэтому беспокойство о том, какой DAL вы используете, кажется отвлекающим маневром.

Сложная часть иногда подключаемых приложений — это найти хорошую систему разрешения конфликтов.Мои предложения:

• Всегда используйте RowGuids в качестве основных ключей к таблицам.Репликация слиянием работает лучше всего, если у вас всегда есть новые записи с уникальным ключом.
• Помните, что репликация слиянием может сделать лишь очень многое:это большой для объединения новых данных в разрозненных системах.Он может даже обнаружить односторонние обновления.Это не мочь волшебным образом определить, что ваша новая запись и моя новая запись на самом деле то же самое и при этом он не может реально справиться с изменениями с обеих сторон без вмешательства человека или правил приоритета.
• По этой причине вам потребуются правила «сопоставления» для разрешения записей, которые претендуют на звание новых, но на самом деле таковыми не являются.Обратите внимание, что это нечеткий шаг:редко вы можете рассчитывать на то, что уникальный ключ будет введен одинаково с обеих сторон и без ошибок.Это означает предоставление взвешенных совпадений, где много ваших показателей одинаковы или похожи.
• Пользовательский интерфейс для разрешения конфликтов и сопоставления «новых» записей с оригиналом должен быть простым в использовании.Я использую что-то похожее на классическое трехстороннее слияние, которое используют многие системы контроля версий:Запись A, Запись B, Объединенная запись.Они могут по умолчанию использовать объединенную запись как A или B, нажав кнопку заголовка, а также могут выбрать каждое поле, щелкнув по ним.Наконец, поля «Объединенные записи» открыты для редактирования, ведь иногда нужно взять части адреса (скажем) из A и Б.

Ничто из этого не должно ни в малейшей степени повлиять на ваш уровень доступа к данным:все это либо более низкий уровень (репликация слиянием, предоставляемая самой базой данных), либо более высокий уровень (разрешение конфликтов, предусмотренное вашими бизнес-правилами для разрешения), чем ваш DAL.

Answer 2

Если вы можете установить систему БД локально, найдите то, что вам знакомо. Самой большой проблемой, я думаю, будет синхронизация и слияние. Вы должны подумать о нескольких возможностях: изменить то, что кто-то еще удалил на сервере. Кто решает?

Никогда не использовал фреймворк Sync самостоятельно, просто прочитал статью. Но это может дать вам прочную основу для дальнейшего развития. Но при каждом доступе к данным решение businesslogic, вероятно, будет оказывать гораздо более широкое влияние ...

Answer 3

В 2004 году было выпущено примерное приложение под названием IssueVision.
http://windowsclient.net/downloads/folders/starterkits/entry1268.aspx

Нашел ссылку на старую ветку на joelonsoftware.com. http://discuss.joelonsoftware.com/default.asp?joel.3.25830. 10

Другие идеи ...
Как насчет мобильной широкополосной связи? Завтра сработает пара сотовых карт 3G, и ваше приложение не будет нуждаться в изменениях без больших страниц / графики.

Таблица Excel, используемая в полевых условиях. DTS или SSIS для импорта данных в приложение. В то время как «лучше» решение создано.

Удачи!

Answer 4

Если под SP вы подразумеваете хранимые процедуры ... Я не уверен, что понимаю ваши рассуждения о попытке отойти от них. Учитывая, что они быстрые, проверенные и уже написаны для вас (т.е. проверены).

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

Я бы попытался установить локальную копию базы данных, а затем отправить все затронутые записи, начиная с последнего подключенного периода, в главную базу данных, когда она подключится.