none
desarrollar proyecto complejo en asp.net MVC, ventajas y desventajas ¿? RRS feed

  • Pregunta

  • Iré al grano, que tal se comporta asp.net MVC en un desarrollo de un software de tipo ERP

     


     una reseña resumida de wikipedía


    Los ERP son sistemas de gestión de información que integran y automatizan muchas de las prácticas de negocio asociadas con los aspectos operativos o productivos de una empresa.
    Otra gracia de los ERP es que pueden ser usados por distintas empresas, es decir se deben tener un modulo de configuración que permita la adaptación de la empresa en el software.
    Por ende las soluciones ERP en ocasiones son complejas y difíciles de implantar debido a que necesitan un desarrollo personalizado para cada empresa partiendo de la parametrización inicial de la aplicación que es común.
    Abarca distintas aéreas de una empresa como: producción, ventas, compras, logística, contabilidad (de varios tipos), gestión de proyectos, inventarios y control de almacenes, pedidos, nóminas, etc. ERP se define como la integración de todas estas partes.

     

     

    Como creen Uds. que MVC se comportaría en un desarrollo de estas características, si crees que MVC no es lo mejor que recomendarías?

     

     

    Agradeciendo como siempre sus respuestas

    Atte. Mainer Núñez

    jueves, 14 de abril de 2011 13:00

Respuestas

  • Nosotros llevamos desarrollando aplicaciones de línea de negocio con MVC desde la beta de MVC 1.0 y estamos encantados. La última aplicación, que empezamos hace un año con MVC 2.0, y que pasamos a MVC 3.0 en cuanto salió la RTM es una aplicación también de línea de negocio muy compleja que usa una base de datos con más de 250 tablas, se integra con un sistema de BPM (Bussines Process Management) llamado AgilePoint al que accedemos mediante servicios web y utilizamos la Task Parallel Library, tenemos nuestro propio visor de procesos que muestra de forma gráfica el workflow. Utilizamos SQL Server 2008 R2 como sistema de base de datos y nos integramos con reporting services, tenemos nuestro mini Report Manager dentro de nuestra aplicación. La seguridad de los informes la manejamos nosotros mismos con seguridad basa en roles de aplicación, a cada carpeta de Reporting Services le asignamos los roles que pueden ejecutar los informes de esa carpeta, y los datos que muestran los informes son sólo los que el usuario puede ver ya que cada informe tiene el parámetro UserId que se lo pasamos desde la aplicación. Precisamente el visor de informes es la única página WebForms de la aplicación, ya que usamos el control ReportViewer.

    Al principio cometimos un error que estamos pagando todavía. Es no usar las áreas de ASP.NET MVC, al ser una aplicación tan compleja, nos hubiera venido muy bien tener mejor organizada los controles y acciones. Hasta el momento tenemos una 1200 aciones y creciendo.

    Otra cosa importante a la hora de afrontar la aplicación es seguir una serie de principios y aplicar correctamente el patrón MVC, hay que cambiar el chip de la programación en WebForms. Es importante tener una capa de servicios, sino al final terminas con montones de métodos de los controladores que no deberían ir allí violando el SRP (Single Responsability Principle).

    En cuanto al acceso a datos nosotros utilizamos nuestro propio ORM, llamado ORMLite, siempre hemos querido publicarlo como Open Source, pero nunca encontramos el momento. Es un ORM muy muy simple que no tiene la mayoría de funcionalidades que pueda tener NHibernate o EF, pero es nuestro y tenemos todo el control sobre él. Si no hubiera sido así nos hubiera costado un triunfo implementar alguno de los requisitos que nos pedía el cliente y algunas funcionalidades un poco especiales como el reintento automático de las consultas en caso de fallo. Éste último surgió como consecuencia de la necesidad de resolver el problema de los interbloqueos y nos vino a resolver también el problema de los microcortes en la conexión con SQL Server.

     

     

    • Propuesto como respuesta eduard tomàsMVP lunes, 18 de abril de 2011 14:26
    • Marcado como respuesta Mainer_Nunez martes, 19 de abril de 2011 13:25
    sábado, 16 de abril de 2011 9:55

Todas las respuestas

  • En mi opinion lo mejor es usar MVC ya que es la tecnologia a donde se dirige la web por el momento, la mayoria de lenguajes tiene su framework MVC, ruby tiene rails, php tiene cakephp, code igniter y un monton mas, python tiene djando y  pylon, java tiene springmvc y grails. Es cierto que ASP.NET web forms te puedad ahorrar tiempo pero ese tiempo despues lo vas a gastar resolviendo otros inconvenientes que trae esa tecnologia como el viewstate, y el desorden que permite a los desarrolladores, ademas el performance es mucho mas bajo al de ASP.NET MVC. Ahora si tu o tu equipo de desarrollo no tiene mucha experiencia en MVC es de evaluarlo bien porque muchas cosas se hacen diferente en MVC a comparacion de ASP.NET web forms, asi que no pienses que tu conocimiento de webforms es transferible a MVC, algunas cosas si pero la mayoria creeria que no aplican.
    viernes, 15 de abril de 2011 17:33
  • Nosotros llevamos desarrollando aplicaciones de línea de negocio con MVC desde la beta de MVC 1.0 y estamos encantados. La última aplicación, que empezamos hace un año con MVC 2.0, y que pasamos a MVC 3.0 en cuanto salió la RTM es una aplicación también de línea de negocio muy compleja que usa una base de datos con más de 250 tablas, se integra con un sistema de BPM (Bussines Process Management) llamado AgilePoint al que accedemos mediante servicios web y utilizamos la Task Parallel Library, tenemos nuestro propio visor de procesos que muestra de forma gráfica el workflow. Utilizamos SQL Server 2008 R2 como sistema de base de datos y nos integramos con reporting services, tenemos nuestro mini Report Manager dentro de nuestra aplicación. La seguridad de los informes la manejamos nosotros mismos con seguridad basa en roles de aplicación, a cada carpeta de Reporting Services le asignamos los roles que pueden ejecutar los informes de esa carpeta, y los datos que muestran los informes son sólo los que el usuario puede ver ya que cada informe tiene el parámetro UserId que se lo pasamos desde la aplicación. Precisamente el visor de informes es la única página WebForms de la aplicación, ya que usamos el control ReportViewer.

    Al principio cometimos un error que estamos pagando todavía. Es no usar las áreas de ASP.NET MVC, al ser una aplicación tan compleja, nos hubiera venido muy bien tener mejor organizada los controles y acciones. Hasta el momento tenemos una 1200 aciones y creciendo.

    Otra cosa importante a la hora de afrontar la aplicación es seguir una serie de principios y aplicar correctamente el patrón MVC, hay que cambiar el chip de la programación en WebForms. Es importante tener una capa de servicios, sino al final terminas con montones de métodos de los controladores que no deberían ir allí violando el SRP (Single Responsability Principle).

    En cuanto al acceso a datos nosotros utilizamos nuestro propio ORM, llamado ORMLite, siempre hemos querido publicarlo como Open Source, pero nunca encontramos el momento. Es un ORM muy muy simple que no tiene la mayoría de funcionalidades que pueda tener NHibernate o EF, pero es nuestro y tenemos todo el control sobre él. Si no hubiera sido así nos hubiera costado un triunfo implementar alguno de los requisitos que nos pedía el cliente y algunas funcionalidades un poco especiales como el reintento automático de las consultas en caso de fallo. Éste último surgió como consecuencia de la necesidad de resolver el problema de los interbloqueos y nos vino a resolver también el problema de los microcortes en la conexión con SQL Server.

     

     

    • Propuesto como respuesta eduard tomàsMVP lunes, 18 de abril de 2011 14:26
    • Marcado como respuesta Mainer_Nunez martes, 19 de abril de 2011 13:25
    sábado, 16 de abril de 2011 9:55