Extensibilité sans Open Source

Question

Mon entreprise est en train de créer un grand progiciel multi-niveaux en C #. Nous avons adopté une approche SOA à la structure et je me demandais si quelqu'un a des conseils quant à la façon de le rendre extensible par les utilisateurs ayant des connaissances de programmation.

Cela implique un processus en deux volets: l'approbation par l'administrateur d'un système de production pour permettre à un plug-in spécifique à utiliser, ainsi que l'architecture de plug-in réel lui-même

.

Nous voulons permettre aux utilisateurs d'écrire des scripts pour effectuer des tâches courantes, modifier la mise en page de l'interface utilisateur (écrit en WPF) et ajouter de nouvelles fonctionnalités (par exemple. Permettant la cartographie des données sous forme de tableaux). Quelqu'un at-il des suggestions sur la façon de mettre en œuvre, ou savoir où l'on peut obtenir les connaissances nécessaires pour faire ce genre de chose?

Je pensais que ce serait le coin le cas parfait pour libérer le logiciel open-source avec une licence restrictive sur la distribution, cependant, je ne suis pas désireux de permettre l'accès de la concurrence à notre code source.

Merci.

EDIT: Je voudrais apporter une précision pour expliquer pourquoi j'ai choisi la réponse que je l'ai fait. Je faisais référence aux administrateurs de production externes à mon entreprise (ie. Le client), et en leur donnant someway pour automatiser / les choses de script d'une manière plus facile sans les obliger à avoir une connaissance complète de c # (ils sont pour la plupart des utilisateurs finaux avec une programmation limitée expérience) - je pensais plus d'un DSL. Cela peut être un objectif hors de portée et le Managed Extensibility Framework semble offrir à ce jour le meilleur compromis.

Answer 1

Je prendrais un coup d'œil à l'initiative MEF de Microsoft. Il est un cadre qui vous permet d'ajouter à vos applications d'extensibilité. Il est en version bêta maintenant, mais devrait faire partie de .Net 4.0.

Microsoft partage la source, afin que vous puissiez regarder comment il est mis en œuvre et de l'interface avec elle. Donc, fondamentalement, votre cadre sera ouvert extensible pour tout le monde à regarder, mais il ne vous forcera pas à publier votre code d'application ou le code plug-ins.

Answer 2

Il suffit d'utiliser les interfaces. Définir un IPlugin que chaque plug-in doit mettre en œuvre et utiliser une couche de messagerie bien définie pour permettre le plug-in d'apporter des modifications dans le programme principal. Vous voudrez peut-être regarder un programme comme MediaPortal ou MeediOS qui dépendent fortement des plug-ins de l'utilisateur.

Answer 3

Comme mentionné par Steve, en utilisant des interfaces est probablement la voie à suivre. Vous auriez besoin de concevoir l'ensemble d'interfaces que vous voulez que vos clients à utiliser, les points d'entrée de conception pour les plug-ins ainsi qu'un modèle de communication de plug-in. Avec les suggestions de Steve, vous pouvez également jeter un oeil au projet Eclipse . Ils ont une architecture de plugin très bien défini, et même si son écrit en Java, il peut être utile de jeter un coup d'oeil.

Une autre approche pourrait consister à concevoir une API disponible pour un langage de script. Tous les deux IronPython et Boo sont les langages de script dynamiques qui fonctionnent bien avec C #. Avec cette approche, vos clients peuvent écrire des scripts pour interagir avec et étendre votre application. Cette approche est un peu plus d'une solution légère par rapport à un système de plug-in complet.

Answer 4

Open source n'est pas nécessaire dans une forme ou une façon de faire un extensible produit.

Answer 5

Je suis d'accord que l'open source est une idée effrayante dans cette situation. Lorsque vous dites que l'approbation par un administrateur de production - est que l'administrateur au sein de votre entreprise, ou externe

?

Personnellement, je regardais par héritage permettant l'extensibilité (permettant à des tiers de sous-classe votre code sans leur donner la source) et les modificateurs d'accès très soigneusement spécifiés.

Answer 6

Microsoft a déjà fait exactement cela, ce qui Reporting Services, qui a tous les attributs que vous mentionnez: mise en page définie par l'utilisateur, scriptabilité, des graphiques, interface utilisateur personnalisable. Cela comprend un IDE téléchargeable. Pas d'accès au code source est fourni ou nécessaire, mais il est absolument jonché de crochets d'extensibilité. L'absence de code source inhibe le couplage et à proximité favorise la pensée SOA.

Answer 7

Nous sommes actuellement dans une situation similaire. Nous avons identifié les différents scénarios où les gens peuvent vouloir créer une connexion en direct sur un niveau de données. Dans ce cas, ils peuvent avoir accès à un webservice sinle à la demande et importer des données.

À un certain moment, ils voudront peut-être avoir une interface utilisateur personnalisée (dans notre cas Silverlight 2). Pour ce scénario, nous pouvons fournir une classe de base et lui demander d'inscrire le module dans un référentiel central. Il intègre ensuite dans notre application de manière uniforme, y compris la sécurité, la forme et le comportement et l'interaction avec les services.