¿Cuáles son algunas cosas comunes a tener en cuenta al desarrollar una aplicación basada en web para ser vendida [cerrado]

Question

Estoy desarrollando una aplicación para un cliente interno. Uno de los requisitos es que se desarrolle de tal manera que se pueda vender a otras organizaciones. La aplicación es una aplicación de seguimiento para una organización de recaudación de fondos que gestionará sus donaciones, donantes, participantes y eventos. Ya sé que necesitaré desarrollar una arquitectura de complemento para la autenticación (la autorización se manejará internamente) y derivar datos demográficos de un directorio externo.

La aplicación se compilará en ASP.NET/C#/Linq/SQL Server. En este punto, no estoy realmente abierto a admitir bases de datos alternativas, pero creo que podría hacerlo en el futuro a través de diferentes controladores Linq, si es necesario.

Todas las aplicaciones web que he creado hasta la fecha han sido implementaciones personalizadas, así que me gustaría saber si hay otras cosas que necesito abordar a través de complementos y / o elementos de configuración. Cualquier aportación sería útil.

Gracias.

Answer 1

Quiero advertirle que no intente hacer que "hacer todo" marco de referencia. Este es un error común que muchos desarrolladores cometen al intentar crear sus primeras aplicaciones de software para el mercado masivo.

Ya tiene un cliente y es probable que esté financiando la versión inicial de la aplicación. Debe entregar la mayor cantidad de lo que este cliente necesita lo más rápido posible o falla antes de siquiera pensar en el mercado masivo.

Hazte un favor y espera que este sea el único cliente que NUNCA usará o comprará la aplicación. Diseñe su aplicación más o menos de la misma manera que hubiera diseñado cualquiera de sus otras aplicaciones personalizadas en el pasado.

Todo lo que necesita hacer para escalarlo a otros clientes más adelante es apegarse a las características y funcionalidades de asp.net en la medida de lo posible, mantenerlo lo más simple y ágil posible, y cortar la mayor cantidad ''. avanzado " características de la versión 1.x como puede salirse con la suya.

1.x será su campo de pruebas. Asegúrese de entregar una aplicación que haga lo que su cliente inicial necesita que haga y que lo haga extremadamente bien.

Si tiene éxito y 1.x realmente cumple con la mayoría de los requisitos iniciales de su cliente, entonces sabrá que también tiene una aplicación que satisfará la mayoría de las necesidades de cualquiera de sus clientes. ¡Enhorabuena, ya está a punto de tener una aplicación comercial viable!

Cosas a tener en cuenta:

1. ¿Realmente necesita soportar múltiples plataformas de bases de datos? Claro, es posible que tenga "algunos" clientes que podrían "preferir" MySql a SQL Server. Estará tentado a intentar escribir un DAL mágico que pueda admitir Oracle, MySQL, VistaDB, SQL Server, etc. simplemente cambiando algunas opciones de configuración o haciendo la selección correcta en un instalador. Pero el hecho es que este tipo de '' plataforma '' la neutralidad agrega una complejidad masiva a su diseño e impone severas limitaciones sobre las características que aprovecha. Cosas como el patrón de diseño del proveedor pueden hacerte creer que este tipo de diseño no es tan difícil ... pero estarías equivocado. Sea pragmático y diseñe su aplicación para que sea aceptable para el 90% de su mercado potencial. Con el acceso a datos en particular, generalmente es seguro decir que el 90% o más del mercado dispuesto a instalar y ejecutar una aplicación ASP.NET también es capaz y está dispuesto a usar SQLExpress o SQL Server. En la mayoría de los casos, ahorrará mucho más dinero y tiempo diseñando solo para el servidor SQL del que obtendrá en ventas adicionales si admite varias bases de datos.

2. Intenta evitar hacer " todo " configurable a través de herramientas de administración en línea. Por ejemplo, tendrá la tentación de tener TODO el texto en la aplicación configurable por las herramientas de administración. Eso es genial, pero también es caro. Tarda más en desarrollarse, requiere que aumente el alcance de su aplicación para incluir todo un desorden de herramientas de administración que de otro modo no habría necesitado, y hace que la aplicación sea más compleja y difícil de usar para el 90% de sus clientes eso no importa el texto predeterminado.

3. Considere cuidadosamente la localización. Si no cree que tendrá un gran mercado internacional en un solo idioma. La localización no es demasiado difícil, pero complica un poco cada aspecto de su código ... y eso suma mucho en cualquier aplicación de cualquier tamaño. Mi regla de oro es apuntar solo al idioma de mi mercado inicial. Si la aplicación tiene interés en otros mercados, entonces regreso y hago la localización en la versión 2.x después de recuperar algo de efectivo de la versión 1.0 y probar que la aplicación tiene un mercado viable en primer lugar. Pero si sabe que estará en más de un idioma o cultura, apoye la localización desde el principio.

4. Para la versión 1.0, no se preocupe demasiado por los módulos integrados o las API de servicio sofisticadas. Si ya tenía mucha experiencia en marcos reutilizables, podría tener estas cosas en la versión 1.0, pero si carece de experiencia en este tipo de arquitecturas, perderá demasiado tiempo en estas características en la versión 1.xy usted probablemente todavía se equivoque y tenga que volver a diseñar en la versión 2.x de todos modos.

5. Asegúrese de que la aplicación tenga REALMENTE buenos informes. Para el tipo de aplicación de la que está hablando, esto será lo que decida si la aplicación tiene un mercado. Necesita informes bonitos que no solo se puedan ordenar / filtrar en la pantalla, sino que también se puedan imprimir. Ponga su dinero y tiempo en esto fuera de la puerta.

Answer 2

Lo más importante es diseñarlo de tal manera que sea completamente genérico, es decir, no hay información específica del cliente codificada o incrustada.

Cualquier cosa específica del cliente debe ser configurable a través de metadatos. La forma de hacerlo depende completamente de usted, pero las formas principales son a través de XML, bases de datos o archivos de propiedades.

Si lo diseña de esta manera, podría venderse a cualquier número de clientes que tendrán sus propios archivos o datos de configuración.

Answer 3

Abarax dio una gran respuesta, enfatizaría que debe considerar la localización, tanto para los idiomas hablados (inglés, francés, alemán, etc.) como para el idioma de la organización, p. algunos lugares pueden llamarlo una hoja de tiempo, expediente u orden de trabajo, y cada uno se quejará y se quejará si todo no coincide con lo que siempre han llamado algo.

Answer 4

Si está utilizando tecnologías de código abierto, dedique un poco de tiempo a mantener toda la información de la licencia en un solo lugar.