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

Question

Я работаю над приложением CRUD, которое будет в основном использоваться командами (2-4) социальных работников и медсестер для отслеживания информации о пациенте в форме плана. Приложение представляет собой переоценку приложения ASP.Net, которое было создано до моего времени. В четырех базах данных имеется около 200 таблиц. Версия веб-приложения сильно зависит от SP, но поскольку эта версия является приложением winform, которое будет указывать на локальный db, я не вижу причин продолжать работу с SP. Также следует отметить, что я планировал использовать репликацию Merge для обработки части Sync'ing, и, похоже, некоторые проблемы с этими двумя вместе.

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

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

Спасибо!

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

Существует образец приложение под названием Microsoft issueVision потушить еще в 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 4

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

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

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