Application parfois connectée CRUD DAL

Question

Je travaille sur une application parfois connectée CRUD qui sera principalement utilisée par des équipes (2-4) d’assistantes sociales et d’infirmières afin de suivre les informations des patients sous la forme d’un plan. L'application est une nouvelle version d'une application ASP.Net créée avant mon heure. Il y a environ 200 tables sur 4 bases de données. La version Web App s'appuie fortement sur les SP, mais comme cette version est une application Winform qui pointe vers une base de données locale, je ne vois aucune raison de continuer avec les SP. A noter également que j'avais prévu d'utiliser la réplication de fusion pour gérer la partie Sync'ing et qu'il semble y avoir quelques problèmes avec ces deux éléments ensemble.

J'essaie de comprendre quelle approche utiliser pour le DAL. J'avais initialement prévu d'utiliser LINQ to SQL mais j'ai lu des informations indiquant que cela ne fonctionnait pas dans un paramètre de connexion parfois. J'ai donc essayé de lire et d'expérimenter de nombreuses solutions; SubSonic, NHibernate, Entity Framework. C’est une application relativement simple et due à un problème "imminent" Dans la nouvelle version, cet effort peut être limité "jetable". L’accent est mis sur l’obtention d’une version de bureau opérationnelle sous ASAP.

Ce que je demande ici, c’est que toute personne ayant une expérience quelconque de l’utilisation de l’une de ces technologies (ou de celle que je n’ai pas énumérée) me prêter votre sagesse durement acquise. Quelle est ma meilleure approche, à votre avis, à poursuivre? Avez-vous d'autres idées sur la création de ce type d'application? Je suis vraiment aux prises avec la partie DAL de ce programme.

Merci!

Answer 1

Si les procédures stockées font ce que vous voulez, je dirais que je doute que vous obtiendrez des avantages en les jetant et en les réimplantant. De plus, peu importe si vous utilisez des procédures stockées ou un accès aux données de style LINQ to SQL lorsque vient le temps de répliquer vos données dans la base de données master. Par conséquent, s’inquiéter du DAL que vous utilisez semble être un fil rouge.

Le problème avec les applications parfois connectées est de trouver un bon système de résolution des conflits. Mes suggestions:

• Toujours utiliser RowGuids comme clé primaire pour les tables. La réplication de fusion fonctionne mieux si vous avez toujours de nouveaux enregistrements à clé unique.
• Réalisez que la réplication de fusion ne peut que faire beaucoup: c'est génial de rassembler de nouvelles données dans des systèmes disparates. Il peut même comprendre des mises à jour unilatérales. Il ne peut pas déterminer comme par magie que votre nouvel enregistrement et mon nouvel enregistrement sont réellement identiques . Il ne peut pas non plus traiter des modifications des deux côtés sans intervention humaine ni règles de priorité. / li>
• Pour cette raison, vous aurez besoin de " correspondance " règles pour résoudre les enregistrements qui prétendent être nouveaux, mais qui ne le sont pas. Notez qu’il s’agit d’une étape floue: vous pouvez rarement compter sur une clé unique pour saisir exactement la même chose des deux côtés et sans erreur. Cela signifie donner des correspondances pondérées lorsque plusieurs de vos indicateurs sont identiques ou similaires.
• Interface utilisateur pour la résolution des conflits et la mise en correspondance de "nouveau". les enregistrements avec les originaux doivent être faciles à utiliser. J'utilise quelque chose qui ressemble au fusionnement classique à trois voies utilisé par de nombreux systèmes de contrôle de code source: enregistrement A, enregistrement B, enregistrement fusionné. Ils peuvent définir par défaut l'enregistrement fusionné sur A ou B en cliquant sur un bouton d'en-tête et sélectionner chaque champ en cliquant également sur eux. Enfin, les champs d’enregistrements fusionnés sont ouverts à l’édition, car il est parfois nécessaire de prendre des parties de l’adresse (par exemple) de A et B.

Rien de tout cela ne devrait affecter votre couche d'accès aux données. Il s'agit soit de niveau inférieur (réplication de fusion, fourni par la base de données elle-même), soit de niveau supérieur (résolution de conflit, fourni par vos règles de gestion) par rapport à votre DAL. .

Answer 2

Si vous pouvez installer un système de base de données localement, choisissez quelque chose avec lequel vous vous sentez familier. Je pense que le plus gros problème sera la synchronisation et la fusion. Vous devez penser à plusieurs possibilités: Changé quelque chose que quelqu'un d'autre a supprimé sur le serveur. Qui décide?

Je n'ai jamais utilisé le framework Sync moi-même, il suffit de lire un article. Mais cela peut vous donner une base solide sur laquelle bâtir. Mais chaque fois que vous allez avec un accès aux données, la solution de Businesslogic aura probablement un impact beaucoup plus large ...

Answer 3

Il existe un exemple d'application appelée IssueVision Microsoft publiée en 2004.
http://windowsclient.net/downloads/folders/starterkits/entry1268.aspx

Lien trouvé sur l'ancien fil de discussion dans joelonsoftware.com. http://discuss.joelonsoftware.com/default.asp?joel.3.25830. 10

Autres idées ...
Qu'en est-il du haut débit mobile? Un couple de cartes cellulaires 3G fonctionnera demain et votre application ne nécessitera aucun changement sans grandes pages / graphiques.

Feuille de calcul Excel utilisée sur le terrain. DTS ou SSIS pour importer des données dans l'application. Bien qu'un "meilleur" la solution est créée.

Bonne chance!

Answer 4

Si par SP, vous entendez des procédures stockées ... Je ne suis pas sûr de comprendre votre raisonnement lorsque vous essayez de vous en éloigner. Considérant qu'ils sont rapides, éprouvés et déjà écrits pour vous (c'est-à-dire testés).

Certes, si vous créez une application qui imitera l’original, il y a un avantage certain à conserver autant que possible la base de code originale (fonctionnelle) - dont le moindre est la vitesse.

J'essayais d'installer une copie locale de la base de données, puis de transférer tous les enregistrements concernés depuis la dernière période connectée vers la base de données maîtresse lorsqu'elle s'est connectée.