Passer de l'interface client ms-access au fichier exécutable

Question

Existe-t-il un objet similaire aux formulaires ms-access dans VB, .NET ou d'autres technologies Microsoft?

Nous utilisons maintenant Access pour développer des interfaces client avec un certain succès au cours des 2 dernières années. Nous utilisons une série d'outils de développement faisant le meilleur usage d'un métamodèle (nous avons des tables pour les formulaires, les requêtes locales, les menus, les contrôles, les connexions, etc.) et nous nous en tenons à de solides techniques de programmation. situé soit dans des modules ou des modules de classe.

Ainsi, le code VB détenu sous forme a été rendu standard et sa production est totalement automatisée, en ajoutant des événements prédéfinis aux contrôles en fonction de leurs types (cela a déjà été brièvement exposé here). A l'exception de ces formulaires, tous les autres objets que nous utilisons peuvent être extraits des fichiers Access/mdb: les tables locales peuvent être sauvegardées en tant que fichiers xml, les modules peuvent être exportés en tant que fichiers de base visuels/réécrit dans une autre langue. Nous n'utilisons aucune macro (sauf la macro 'autoexec'), les rapports (nous utilisons un complément Crystal Reports) ou les requêtes (stockées dans une table 'requêtes')

Recherche d'un objet "forms" similaire dans une autre technologie nous donnerait alors la possibilité de distribuer des fichiers d'exécution autonomes/.exe au lieu de notre combinaison actuelle d'un fichier .mdb et de l'exécution ms-access.

Answer 1

À mon avis, la réponse principale doit être fenêtres régulières formes, ou si vous préférez (et être à jour) WPF. Les deux ont un bon support pour la liaison de données, etc, cependant, ni l'un ni l'autre ne sont directement comparables aux formulaires ms-access. Et de telles formes ne peuvent pas être stockées isolément, mais n'existent réellement que dans le cadre d'un assemblage. Eh bien, WPF peut exister un bit plus autonome que xaml, mais même alors, il y a presque toujours beaucoup de code-behind (qui fait partie de l'assemblage, pas détachable).

Answer 2

Je présume que je ne comprends pas la question, mais il me semble que vous posez des questions sur WinForms et/ou WPF. Les formulaires client .NET Windows de base.

Ce serait l'endroit pour commencer. En ce qui concerne l'utilisation que l'on

http://windowsclient.net/getstarted/

, je ne suis pas moi-même réel effacer. Alors j'ai demandé

When is Windows Forms the correct choice vs WPF?

Answer 3

Vous constaterez que vous avez besoin de recoder ces formulaires, peu importe ce que vous faites, car aucune autre application n'a la même architecture que MS Access. WinForms dans VB.NET ne sont pas vraiment les mêmes, et ont plusieurs pièges pour les développeurs expérimentés de MS Access.

Vous trouverez peut-être que la meilleure idée est d'opter pour quelque chose comme WPF, simplement parce qu'il est si différent que cela peut aider vos développeurs à se concentrer sur ce qu'ils doivent faire, plutôt que d'essayer de le contourner.

On ne sait pas très bien quelle logique métier résiderait de toute façon dans ces formulaires. Ils devraient être de simples codes de validation frontaux, avec au pire des liens de données et des manipulations d'événements. Vous devez toujours pouvoir automatiser vos formulaires en fonction de vos tables? Dans ce cas, une forme de générateur de code pourrait aider (bien que ce ne soit pas une excellente stratégie de conception de GUI à utiliser).