practices practice net mvc best asp architecture asp.net-mvc-5 enterprise solution

architecture - net - mvc areas best practice



¿Cuál es la mejor práctica para la arquitectura de aplicaciones de nivel empresarial utilizando MVC5? (2)

Me preguntaba cuál es la mejor práctica para la arquitectura de nivel empresarial basada en MVC5. ¿Me refiero a la selección entre varias capas o múltiples proyectos en una solución? y o tal vez más de una solución? ¿Algún buen proyecto de ejemplo?

Dado que mi pregunta ha sido muy visitada en el último año y no hay una respuesta sólida, ya que soy consciente de ello, decidí brindar una respuesta lo más completa posible. Esta respuesta se basa en la experiencia de algunos proyectos reales y con pocas consultas de expertos:

  1. En primer lugar, es importante tener en cuenta que en el proceso de diseño de software, no hay nada como lo correcto y lo incorrecto. Mientras un enfoque funcione para su proyecto y se adapte bien, es right y si no lo hace, es wrong . No hay principios rígidos en el diseño de software. Hay Project needs and specifications . Pero, en general, se ha aceptado el uso de Design Patterns and Principles hace que el proyecto sea más robust , reliable y easy to maintain y hace que su código esté loosely coupled and highly cohesive .
  2. Toda la historia del Software Design and Architecture del Software Design and Architecture trata de cómo podría administrar su proyecto fácilmente y cómo podría mantener sus cambios futuros. Piensa en qué enfoque te da la mejor respuesta sobre ellos. Eso será lo mejor para ti. ¡No pienses demasiado en el Professionalism ! .Su proyecto crece con el tiempo y se vuelve más maduro. Así que solo piensa en tu proyecto!
  3. Como primer paso y para la arquitectura de aplicaciones de nivel empresarial, siempre intente seguir la Separation of Concerns o SoC . Esto significa que debe tener diferentes niveles para diferentes capas de su proyecto. Se recomienda encarecidamente utilizar diferentes proyectos en su solución para Data Access Layer , Domain Entities , Business Layer y Presentation Layer . En el proyecto MVC5, es mejor usar el Class Library Project para la Data Access Layer , las Domain Entities , Business Layer y un proyecto MVC para la Presentation Layer .
  4. Data Access Layer es el proyecto que se enfrenta a las interacciones de base de datos y base de datos. Podría tener todo su Entity Framework o entidades similares en este proyecto. Tener una capa separada para la capa de base de datos significa que, en el caso de cambiar el almacén de datos de su proyecto, lo único que necesita cambiar es cambiar este proyecto y algunos cambios menores en su Business Layer . Todos los demás proyectos en su solución permanecen intactos. Por lo tanto, puede pasar fácilmente de MS Sql a Oracle o de Entity Framework a NHibernate .
  5. Domain Entities es el proyecto que utilizo para definir todas mis interfaces, clases, enums y variables de nivel de solución. Este proyecto mantiene la integridad a través de mi solución en mis clases y mis métodos. Mis todas las clases en la solución completa se heredan de las interfaces en este proyecto. Por lo tanto, tengo un lugar para cambiar mis clases o variables globales y significa Easy to Maintain para el futuro en mi solución y fácil de entender para los desarrolladores recién incorporados al proyecto.
  6. Business Layer es el lugar donde coloco mi lógica empresarial, incluidas las Business Entities Business Services y los Business Services . La idea general acerca de esta capa es tener un lugar para mantener todos sus métodos e interacciones comerciales. Todos los cálculos, la modificación de objetos y toda la lógica sobre los datos, incluidos el guardado, la recuperación, el cambio, etc., deben realizarse en esta sección. Al tener esta capa en su proyecto, podría tener diferentes consumidores al mismo tiempo, por ejemplo, un MVC nativo y una capa Web API . O bien, podría proporcionar una alimentación diferente según las diferentes especificaciones de los consumidores de servicios empresariales. Se recomienda encarecidamente evitar colocar cualquier lógica empresarial en la sección del controlador de la capa MVC. Tener cualquier lógica de negocios dentro de los controladores significa que usted usa su capa de presentación como capa de lógica de negocios y viola la Separation of Concerns . Entonces no será fácil cambiar de una presentación a otra o tener diferentes tipos de consumidores para su solución. Es mejor mantener la sección del controlador en MVC lo más delgada posible. Los controladores solo deben tener lógica y métodos directamente relacionados con los View Models . Para obtener más información sobre los View Models consulte la sección 7 . Una cosa para recordar, es mejor tener diferentes clases de Business Services basadas en los objetos de su solución o Business Entities .
  7. Presentation Layer en la solución MVC será un proyecto MVC. Pero la solución podría tener otro tipo o más de una capa de presentación para diferentes consumidores o tecnologías. Por ejemplo, podría tener una capa MVC y una Web API en una solución. En general, utilice la capa de presentación para mantener toda la lógica de presentación en ella. La lógica de presentación no debe tener nada relacionado con la lógica de negocios o la lógica de datos. Entonces la pregunta es ¿qué es la Presentation logic ? Presentation logic es lógica relacionada con los modelos de vista. Los modelos de vista son objetos personalizados para vistas o páginas. En la mayoría de los casos, los objetos comerciales no son adecuados para su uso en vistas. Por otro lado, las vistas de presentación generalmente necesitan algo de lógica de validación o lógica de presentación, por ejemplo, un nombre diferente a los nombres de objetos originales. En estos casos, es mejor mantener la lógica de presentación separada de la lógica de negocios para que sea fácil cambiar la lógica de presentación o la lógica de negocios de manera independiente e incluso cambiar la capa de presentación para diferentes diseños de UI o para cambiar la lógica de negocios para tener más funcionalidad sin temor a interrupciones Lógica de presentación. En el caso de utilizar el proyecto MVC como capa de presentación para la solución, todos los modelos de vista deben colocarse en la sección Models del proyecto MVC y toda la lógica de presentación debe ubicarse en la sección Controllers del proyecto.
  8. Lo último que se debe decir es que para cada solución de múltiples niveles, necesita marcos para la asignación de objeto a objeto, por ejemplo, para convertir su entidad de negocio para ver el modelo. Hay algunas herramientas para este propósito como AutoMapper , BLToolkit y EmitMapper .

Última palabra: por favor, haga un comentario y puntúe la question y mi answer para mejorarla.