¿Cómo se diseña una aplicación web que se debe personalizar para cada nuevo cliente?

Question

Me han encargado que vuelva a escribir una aplicación web bastante grande para una empresa. Esta aplicación proporciona cierto análisis financiero/de riesgo a 3 clientes que tenemos actualmente.

El gran problema de esta aplicación es que cada cliente es diferente y tiene datos ligeramente diferentes. Todos ellos inician sesión en el mismo sitio web pero luego su experiencia puede diferir ligeramente. Sus esquemas de base de datos no son los mismos, ocasionalmente sus puntos de vista tienen que diferir para representar datos diferentes y su administración de usuarios es una pesadilla de complejidad. Cuando un usuario inicia sesión en nuestro sitio, necesitamos extraer datos de la base de datos correcta (cada cliente tiene los suyos propios).

dicen nuestros clientes son 3 empresas de hardware:

• HackmansHardware
• LowesHardware
• FranksHardware

hardware de Hackman podría tener ligeramente diferentes necesidades de análisis o solicitud Certains columnas especiales en nuestros informes. Del mismo modo, Lowes Hardware podría querer tener un acceso de seguridad ligeramente diferente a sus páginas y luego una empresa diferente en función de sus usuarios.

Funcionalmente, la aplicación web es la misma para ellos. Tiene las mismas pestañas y los mismos objetivos con respecto a la información que intenta presentar. Pero hay sutiles diferencias entre ellos que tengo problemas para encapsular y está haciendo que el código sea un desastre.

Pregunta: ¿Cuál es la mejor práctica para manejar una aplicación base que necesita modificaciones para cada cliente nuevo que obtenemos? ¿Qué patrón de arquitectura/diseño podemos usar para hacer que la adición de nuevos clientes sea relativamente sencilla a pesar de su necesidad de personalización y al mismo tiempo volver a utilizarla tanto como sea posible? ¿Cómo podemos mantener nuestra base de código limpia sin la necesidad de hacks por cliente?

Estamos utilizando ASP.NET MVC para esta reescritura, pero no estoy seguro de cuán relevante es la pregunta.

Answer 1

¿Cuántos clientes potenciales espera? Si la respuesta es de 2 nuevos anualmente, su solución será diferente a si dices 200 nuevos clientes anualmente.

Como inicio, parece que se necesita una base de datos de configuración maestra (o archivo). Su aplicación podría usar esta información de configuración para determinar todo lo que se puede personalizar. Después de eso, construir una interfaz de usuario para agregar un cliente es bastante fácil.

Si lo estuviera haciendo (con el poco conocimiento que tengo de su proyecto) ... Comenzaría por crear un modelo de cliente "base". Todos los nuevos modelos de clientes se derivarían de esta base, que contendría toda mi lógica estándar. Para los clientes existentes, puede ser doloroso para ellos, pero a través de una serie de funciones de envoltura y clases de configuración, se puede hacer.

Answer 2

Necesita un "Portal web".

Hay buena información disponible sobre cómo crear portales web en ASP.NET que podría brindarle algunas ideas sobre cómo hacerlo con MVC. En particular, está el DropThings portal, y su libro complementario, Building a Web 2.0 Portal with ASP.NET 3.5. Es posible que pueda adaptar la mayoría o todas sus ideas a ASP.NET MVC.

Answer 3

En última instancia, necesita una forma de describir el esquema en los metadatos que la aplicación puede comprender. Hay muchas maneras diferentes de hacerlo, tendrá que elegir por su cuenta, pero como ejemplo (no necesariamente la mejor opción, o una buena opción):

Use XML para describir el esquema para cada tienda Cree una herramienta que genere un esquema DB basado en el XML. Codifique sus informes para ver el XML y determinar qué columnas mostrar. Continúa hasta la náusea.

Otra opción es mantener el núcleo de la aplicación igual pero crear diferentes implementaciones de partes clave donde difieran. Use una biblioteca de contenedores IoC para cargar las implementaciones apropiadas para cada tienda.

Answer 4

Crea una página maestra que contiene toda la información que es igual para cada cliente. Luego, agregue vistas y/o controladores que sean únicos para cada cliente.

Eche un vistazo al siguiente enlace. Explica cómo crear un "Controlador de aplicación", una clase abstracta que sus otros controladores pueden heredar, de modo que solo tenga que escribir el código una vez que inserte los datos de página maestra necesarios en la vista.

Pasando datos a ver páginas maestras:
http://www.asp.net/learn/MVC/tutorial-13-cs.aspx

También, echar un vistazo al siguiente enlace, que explica cómo implementar Vistas parciales y subcontroladores en ASP.NET MVC:

solicitudes parciales en ASP.NET MVC
http://blog.codeville.net/2008/10/14/partial-requests-in-aspnet-mvc/

Answer 5

La personalización en el nivel de datos siempre es un desafío. Comience con un análisis detallado de qué es exactamente diferente de un cliente a otro. Luego, busque formas de crear un único diseño de datos que encapsule las variaciones. Esto puede ser complicado pero vale la pena el esfuerzo. Si puede tratar de pensar cómo puede crear el diseño para ser lo suficientemente flexible para las necesidades de los futuros clientes (sí, esto puede implicar una bola de cristal).

Desde una perspectiva arquitectónica, considere utilizar un patrón de fábrica de anstract en la capa de acceso a datos. Sin conocer los detalles de los requisitos o el grado de variación de un cliente a otro, no estoy seguro de qué tan aplicable sea esto, pero he tenido éxito en el pasado al usar este patrón para dar cuenta de variaciones bastante amplias en el formato y la estructura de fuentes de datos que deben entregarse a una capa de procesamiento/presentación común. Esto le permitiría crear componentes de capa de datos que se conectan directamente a la interfaz del sistema.

La personalización de la capa de presentación se vuelve un poco más directa y se puede manejar fácilmente a través del usuario de MVC, páginas maestras y temas. Creo que algunos de los otros comentarios/respuestas publicados aquí abordan esos aspectos del proceso de personalización.

Answer 6

Puede ser una buena idea usar una mezcla de código de C# duro y algún lenguaje de scripting como IronPython para resolver su problema. Es bastante difícil crear un archivo de configuración lo suficientemente completo como para describir las diferencias sutiles que ocurren entre los clientes y no se puede usar ningún tipo de lógica en los archivos de configuración (a menos que esté dispuesto a desarrollar otro lenguaje de programación medio cocido).

Intentaré escribir todo lo que sea similar para todas las instalaciones en C# y todo lo que sea diferente entre instalaciones en Python. Además, utilizaría su herramienta de control de origen para gestionar la combinación de la estructura de C# y la configuración de Python.Esto debería proporcionarle un límite bien definido entre el código reutilizable y los requisitos específicos de lógica comercial para cada cliente. Además, dado que los lenguajes de scripting no están compilados, podrá ajustar la configuración en el sitio. En general se considera una mala práctica hacerlo, pero cuando piensas en el código de Python como una configuración glorificada para tu aplicación, puede que no sea tan malo. A medida que las personalizaciones son pirateadas en Python para que los clientes específicos maduren y se conviertan en conceptos reutilizables, los volvería a trabajar en C#, los agregaría al marco y eliminaría las personalizaciones.

Tenga en cuenta que estoy usando C# y IronPython como ejemplos aquí; puede usar cualquier combinación de dos idiomas. Sin embargo, creo que debería haber una diferencia significativa en la sintaxis entre los dos para mantener los límites claros.

Answer 7

Eche un vistazo a la aplicación "multi inquilinos". Aquí multi tenant on so

O aquí Bart blog

Answer 8

voy a tener que estar de acuerdo con algunos de los enfoques que describen derivados de un controlador de base común, etc., porque la subclasificación por sí sola no va a funcionar bien. Agregará clases derivadas para cada cliente y se convertirá en una pesadilla de mantenimiento si tiene más que un puñado de clientes. Además, aunque una página maestra se utilizará en cierta medida, si sus clientes desean ingresar en la apariencia de su sitio, muchas cosas como colores, estilos, etc. necesitarán ser manejadas por datos.

La idea del portal es bastante buena, pero si tiene mucha lógica de dominio personalizado que diferirá de cliente a cliente, también comenzará a convertirse en un problema rápidamente. Si solo se trata de ocultar algunas páginas para algunos clientes, entonces una idea de portal no es una mala sugerencia. Tenga en cuenta que si usa entornos de preproducción, los sitios del portal como DotNetNuke pueden ser difíciles de implementar de un entorno a otro a menos que se familiarice íntimamente con su esquema. Además, los sitios como DotNetNuke no están escritos en MVC, por lo que aplicar prácticas de desarrollo basadas en pruebas será mucho más desafiante que comenzar desde cero.

Primero comenzaría a leer sobre patrones de diseño si no tiene una buena base en ellos, específicamente los patrones de Estrategia y Resumen de fábrica. Esto le permitirá observar el diseño del proyecto con miras a favorecer la dependencia sobre la herencia. Intente desarrollar algunas clases de dominio que expondrán las propiedades que son las plantillas para lo que expondrá a sus clientes. Los tipos de esas propiedades utilizarán las clases que encapsulan lo que puede variar de un cliente a otro. Una vez que construye un par de clases y las prueba, puede generar el esquema de base de datos necesario para admitirlo. Sospecho que terminará con una tabla de clientes, tablas que contendrán los valores posibles para sus entidades y sus tipos de valores relacionados, y tablas para cada uno que asocien a los clientes con estas entidades.

Espero que esto ayude.