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

Question

Я работаю над приложением Some Connected CRUD, которое будет в основном использоваться командами (2-4) социальных работников и медсестер для отслеживания информации о пациентах в форме плана. Приложение представляет собой ревизию приложения ASP.Net, которое было создано до моего времени. Существует около 200 таблиц в 4 базах данных. Версия веб-приложения в значительной степени опиралась на 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 и B.

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

Answer 2

Существует пример приложения под названием IssueVision, выпущенный Microsoft в 2004 году.
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 3

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

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

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

Answer 4

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

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