Quiero advertirle en contra de intentar hacer el marco de "hacer todo". Este es un error común que cometen muchos desarrolladores cuando intentan crear sus primeras aplicaciones de software de mercado masivo.
Ya tiene un cliente, y es probable que estén 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.
Hágase un favor y espere que este es el único cliente que SIEMPRE utilizará o comprará la aplicación. Diseña tu aplicación más o menos exactamente igual a como hubieras diseñado alguna de tus otras aplicaciones personalizadas en el pasado.
Todo lo que necesita hacer para ampliar su escala a otros clientes más tarde es mantener las características y funcionalidades de stock asp.net tanto como sea posible, mantenerlo lo más simple y delgado posible, y reducir el número " funciones "avanzadas" de la versión 1.x, ya que 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, sabrá que también tiene una aplicación que satisfará la mayoría de las necesidades de sus clientes. ¡Felicidades, ya has recorrido la mayor parte del camino hacia una aplicación de mercado comercial viable!
Cosas a tener en cuenta:
lo que realmente necesita para soportar múltiples plataformas de bases de datos? Claro, es posible que tenga "algunos" clientes que podrían "preferir" MySql a SQL Server. Tendrá la tentación de intentar y escribir algún DAL mágico que pueda soportar 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 neutralidad de "plataforma" agrega complejidad masiva a su diseño e impone severas limitaciones sobre las funciones que aprovecha. Cosas como el patrón de diseño del proveedor pueden engañarlo y hacerle pensar que este tipo de diseño no es tan difícil ... pero estaría 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 para el servidor SQL que nunca en ventas adicionales de soporte de múltiples bases de datos.
Trate de evitar que "todo" se pueda configurar 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 costoso. Lleva más tiempo desarrollarse, requiere que aumente el alcance de su aplicación para incluir todo un lío 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 que no le importe el texto predeterminado.
Considere cuidadosamente la localización. Si no cree que tendrá un gran mercado internacional se adhieren a un idioma. La localización no es muy difícil, pero complica un poco cada aspecto de su código ... y eso se suma a 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, vuelvo 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, soporte la localización desde el principio.
Para la versión 1.0, no se preocupe demasiado por los módulos adicionales o las API de servicio sofisticado. Si ya tenía mucha experiencia en marcos reutilizables, podría tener esto en la versión 1.0, pero si no tiene experiencia en este tipo de arquitecturas, perderá demasiado tiempo en estas características en la versión 1.x y probablemente aún se equivocará y tendrá que volver a diseñar en la versión 2.x de todos modos.
Asegúrate de que la aplicación REALMENTE tenga buenos informes. Para el tipo de aplicación de la que está hablando, esto será lo que decida si la aplicación incluso tiene un mercado. Necesita informes bonitos que no solo se puedan ordenar/filtrar en la pantalla, sino que también se puedan imprimir. Pon tu dinero y tiempo en esto fuera de la puerta.
Tengo curiosidad por saber qué pasó con su aplicación y el enfoque que tomó. Sería bueno si hablas de tu experiencia. – user347594