Aplicaciones web: ¿combinar o separar?

Question

Para nuestra empresa, estoy creando un gran sitio web de Extranet que contará con un conjunto de subplicciones. Estoy un poco perplejo por lo que debería ser la configuración correcta de la solución y los proyectos.

Tengo una aplicación web que llamamos al portal. Contiene las clases de autenticación/autorización, MasterPages, clases de enrutamiento de navegación/URL y definiciones de temas. También contendrá algunas descripciones básicas para que nuestros clientes tengan una idea rápida del estado de su proyecto.

En el próximo año vamos a desarrollar e integrar más aplicaciones con el portal. Piense en ello como descripciones y herramientas detalladas llamadas características A, B y C. A lo largo de los años mejoraremos estas aplicaciones y lanzaremos nuevas versiones. Estas aplicaciones web deben encajar en la navegación del portal sin problemas. Me gustaría que reutilicen las maestros y temas.

¿Cuál es la forma correcta de configurar esta solución?
¿Cómo puedo unir las aplicaciones, reutilizar las páginas maestras y mantenerlas mantenibles?
¿Cómo puedo compartir ciertos Controlos web (ASCX) de manera adecuada?
¿Estamos usando TFS, tal vez alguna idea de ramificación/fusión?

Editar:
Me gustaría crearlo en ASP.NET WebForms, tenemos la mayor experiencia en esa área. Pero básicamente podemos usar cualquier cosa, tenemos el servidor web bajo nuestro propio control (siempre que esté orientado a Microsoft, no cambiando a PHP o algo así :))

Answer 1

What is the proper way to setup this solution?

La forma correcta ... hay tantos. He visto muchas aplicaciones y muchas diferente configuraciones (muchas de las cuales lo consideraría "apropiado"). Lo que realmente estás preguntando es para la mejor manera para tu situación.

Debido a que está construyendo un portal, tendrá el lujo de separación de características que lo ayudará a medida que desarrolle funciones adicionales para su aplicación.

Configuraría un solo sitio web con una carpeta separada para cada función. Hacer que sea un solo sitio web permitirá que todas las funciones compartan los mismos MasterPages, UserControls y el archivo de configuración, sin tener que hacer nada especial. (En esa nota, pondría todas sus páginas maestras en una carpeta por sí mismas y crearía otra carpeta para sus usercontrolos).

How can I tie the applications together, re-use the master pages and keep it maintainable?

De nuevo ... las carpetas son la mejor opción aquí. Las carpetas ayudarán a separar cada función, lo que hace que la aplicación sea fácil de administrar.

How can I share certain webcontrols (ASCX) in a proper way?

En primer lugar, los archivos ASCX no son controladores web. Son usercontrolos. WebControl es una clase para crear controles de servidor que residen en un ensamblaje separado. Con respecto a UserControls, como dije anteriormente, si los coloca en una carpeta separada, siempre están en un solo lugar y están disponibles en toda la aplicación.

We are using TFS, perhaps any branching/merging ideas?

Realmente no hay nada especial que debas hacer aquí. Hay muchos caminos diferentes que puede tomar con respecto a la ramificación:

• Una es crear una rama para cada lanzamiento.
• Otra es crear una rama para cada nueva característica que agregue (en su caso, esto es más o menos lo mismo que la primera opción).
• Otro es crear una rama para cada desarrollador.

Cuando decido cómo voy a ramificar mi código, pienso en lo que más me protegerá. En su caso, debe planificar las correcciones de errores entre las versiones de características, por lo que tal vez una rama después de cada lanzamiento tenga más sentido (llámelo su rama de desarrollo). Sin embargo, dada la separación de las características, una característica puede no afectar el resto de la aplicación. Es posible que no necesite este tipo de ramificación para ser segura.

Answer 2

Como Brian dice al hacer un público API, debe comprometerse con él tanto como sea posible, lo que significa que debería cambiar lo menos posible después del lanzamiento inicial. Sin embargo, para hacer algo tan estable requiere mucho esfuerzo por adelantado, por lo que si no está listo para comprometerse con la API, debe internalizarlo tanto como sea posible y, por esa razón, es posible que desee combinar las cosas más que separarlas.

Sin embargo, no voy a sugerir una arquitectura que se ajuste a su aplicación en función de una descripción de 5 párrafos. Lo que debe hacer es peso de los pros y los contras de tener algunos grandes proyectos frente a tener un montón de pequeños proyectos poco acoplados. Quiero decir, cuanta más planificación haga por adelantado, más fácil lo tendrá en el futuro, siempre que se quede con el plan.

Entonces, al contrario de la respuesta de Brians, no le recomendaría que haga que todo su sistema sea "lo más ligeramente acoplado posible", solo que lo hagas tan suelto como sea necesario. ;) El código acoplado libremente puede causar tantos problemas como el código estrechamente acoplado, si lo está abusando.

Ver:
1. ¿Qué es mejor, muchos ensamblajes pequeños o una gran asamblea?
2. ¿Down-lados específicos a muchos de los "pequeños"?

Al final, solo usted sabe cuánto desea concentrarse en cada una de las "... Bilidades", mantenibilidad, extensibilidad, confiabilidad, etc. Así que obtenga sus prioridades y objetivos rectas y planifique en consecuencia.

Con respecto a las estrategias de ramificación, podría leer el Guía de ramificación de TFS 2.0 que tienen una buena introducción a varias estrategias de ramificación que van desde básicas hasta avanzadas. Incluso si no usa TFS, esta es una buena guía para leer (uso SVN en este momento). Como actualmente trabajo en equipos pequeños con 1-4 desarrolladores, tiendo a usar una estrategia que es entre lo básico y el estándar. No es que le recomiendo esto, pero eso es mejor para nuestro equipo.

En cuanto a compartir código entre proyectos. En SVN podemos usar "exterioridad"Lo que significa que el archivo compartido aparecerá en varias carpetas, por lo que cuando cambie una copia y confirme el cambio a SVN, todas las otras copias se actualizarán en la próxima actualización de SVN. Sin embargo, no recuerdo si TFS tiene algo similar. .

Nota: Tenga cuidado con los externos en SVN ... pueden causar ... problemas. ;)

Mi consejo es tratar de evitar compartir las páginas ASPX, ASCX y maestros tanto como sea posible. Por lo general, duele mucho más de lo que ayuda. En su lugar, intente usar la herencia u otras alternativas para lograr su objetivo.

ASP.NET MVC 2.0 tiene un concepto llamado "áreas" donde construye subsecciones de una aplicación de forma aislada del resto. Hasta donde sé, estas áreas pueden mantenerse en proyectos separados de la aplicación "principal". Suena mucho como lo que estás solicitando, así que tal vez deberías investigar eso.

Espero que tenga sentido. ;)

Answer 3

Miraría hacer tu sistema como débilmente acoplado como sea posible. Como/cuando agrega más aplicaciones, su sitio web se volverá cada vez menos confiable (ya que ningún componente aumentará el 100% del tiempo, combinarlas reducirá su confiabilidad general). Por lo tanto, debe construir su sistema para atender los servicios que no son mayores que están inactivos (creo que la página de inicio de Amazon, por ejemplo, tiene servicios de 100 ish que contribuyen y, como tal, está construido para ser tolerante a fallas)

Sus API entre los servicios deben permanecer lo más estables posible, de modo que las implementaciones puedan cambiar sin romper el acoplamiento. También debe investigar las pruebas automatizadas de esto a nivel web (tal vez Selenio o similar?) Dado que probar los servicios individuales le dará poca cobertura sobre el comportamiento general.

Answer 4

Es posible que le resulte útil considerar la implementación de una personalización VirtualPathProvider. En mi último proyecto, teníamos múltiples sitios ASP.NET que necesitaban compartir archivos de tema (páginas maestras, controles de usuario, imágenes, hojas de estilo), así que creé un VirtualPathProvider que nos permitió asignar una carpeta virtual (por ejemplo, temas) a cualquier físico. carpeta en el disco duro (por ejemplo, C: compartido Sitethemes).

No es trivial, pero no llevó demasiado tiempo y no ha causado ningún problema. Por cierto, resultó ser una excelente manera de superar el límite de componente máximo en WIX ... Tenga en cuenta que no puede precompilar sitios que usan un VirtualPathProvider.

Answer 5

Use conceptos MVC a partir de ahora. Dan más extensibilidad y flexibilidad para aplicaciones sólidas.

Answer 6

Puede mirar el uso de SharePoint. Es una plataforma bastante decente para la entrega de aplicaciones ASP.NET, particularmente si coexisten en un entorno de intranet; Te da muchas cosas gratis.

Por supuesto, tiene codos muy difíciles, por así decirlo, así que continúe con precaución.

Answer 7

No pensaría en las aplicaciones como separadas sino como módulos del portal general.

Le recomendaría que busques en MEF, ya que esto parece ser perfecto.

http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx