Extensibilidad y sin código abierto

Question

Mi empresa se encuentra actualmente en el proceso de creación de un gran paquete de software de varios niveles en C #. Hemos adoptado un enfoque SOA para la estructura y me preguntaba si alguien tiene algún consejo sobre cómo hacer que sea extensible por los usuarios con conocimientos de programación.

Esto implicaría un proceso de dos veces: aprobación por el administrador de un sistema de producción para permitir un plugin específico a utilizar, y también la arquitectura de plugin en sí

.

Queremos permitir a los usuarios escribir scripts para realizar tareas comunes, modificar el diseño de la interfaz de usuario (escrito en WPF) y añadir nueva funcionalidad (es decir. Que permite la cartografía de los datos tabulados). ¿Alguien tiene alguna sugerencia de cómo implementar esto, o saber dónde se podría obtener el conocimiento para hacer este tipo de cosas?

Yo estaba pensando que esto sería la esquina caso perfecto para liberar el software de código abierto con una licencia restrictiva sobre la distribución, sin embargo, no estoy interesado en permitir el acceso de la competencia en nuestro código fuente.

Gracias.

EDITAR: el pensamiento que acababa de aclarar para explicar por qué he elegido la respuesta que hice. Me refería a los administradores de producción externas a mi empresa (es decir. El cliente), y dándoles alguna manera para automatizar / cosas de guión de una manera más fácil sin que tengan que tener un conocimiento completo de C # (en su mayoría son los usuarios finales con programación limitada experiencia) - yo estaba pensando más de un DSL. Esto puede ser un objetivo de alcance y el marco de extensibilidad Gestionado parece ofrecer el mejor compromiso hasta ahora.

Answer 1

Me gustaría echar un vistazo en el MEF iniciativa de Microsoft. Es un marco que permite agregar la extensibilidad a sus aplicaciones. Es en fase beta, pero debe ser parte de .Net 4.0.

Microsoft comparte la fuente, para que pueda mirar cómo se implementa y la interfaz con él. Así que, básicamente, su marco de extensibilidad estará abierta para todo el mundo a la vista, pero no te va a obligar a publicar el código de aplicación o el código de plug-ins.

Answer 2

Sólo tiene que utilizar interfaces. Definir un IPlugin que cada plugin debe implementar y utilizar una capa de mensajería bien definido para permitir que el plugin para hacer cambios en el programa principal. Es posible que desee ver en un programa como Mediaportal o Meedios la que en gran medida dependen de los plugins de usuario.

Answer 3

Como se mencionó por Steve, el uso de interfaces es probablemente el camino a seguir. Usted tendría que diseñar el conjunto de interfaces que desea que sus clientes usen, puntos de entrada para el diseño de los plugins, así como un modelo de comunicación plugin. Junto con las sugerencias de Steve, también puede ser que desee tomar un vistazo al proyecto Eclipse . Tienen una arquitectura de plugins muy bien definido y aunque su escrito en Java, puede valer la pena echar un vistazo a.

Otro enfoque podría ser el diseño de una API disponible para un lenguaje de script. Ambos IronPython y Boo son lenguajes de programación dinámicos que funcionan bien con C #. Con este enfoque, sus clientes podrían escribir secuencias de comandos para interactuar y ampliar su aplicación. Este enfoque es un poco más de una solución de peso ligero en comparación con un sistema de plugins completa.

Answer 4

El código abierto no es necesario en cualquier manera o forma para hacer un extensible producto.

Answer 5

Estoy de acuerdo que el código abierto es una idea que da miedo en esta situación. Cuando usted dice que la aprobación de un administrador de producción - es que el administrador de su empresa, o externo

?

En lo personal, me gustaría ver a permitir la extensibilidad por herencia (permitir a terceros a la subclase su código sin darles la fuente) y modificadores de acceso muy cuidadosamente especificados.

Answer 6

Microsoft ya hizo exactamente esto, lo que resulta en Reporting Services, que tiene todos los atributos que mencionas: diseño de usuario, crear scripts, gráficos, interfaz de usuario personalizable definida. Esto incluye un IDE descargable. Sin acceso al código fuente se proporciona o se requiere, sin embargo, está absolutamente llena de ganchos de extensibilidad. La ausencia de código fuente inhibe primer acoplamiento y promueve el pensamiento SOA.

Answer 7

Actualmente nos encontramos en una situación similar. Se identificaron los diferentes escenarios donde la gente puede crear una conexión en directo en un nivel de datos. En ese caso, puedan tener acceso a un servicio web sinle a datos de la solicitud y de importación.

En algún momento es posible que quieran tener una interfaz de usuario personalizada (en nuestro caso Silverlight 2). Para este escenario podemos proporcionar una clase base y hacer que se registran el módulo en un repositorio central. A continuación, se integra en nuestra solicitud de una manera uniforme, incluyendo la seguridad, la forma y el comportamiento e interacción con los servicios.