.net - programa - La estructura de la solución definitiva de Visual Studio

visual studio installer

Question

Al darme cuenta de que esto podría ser subjetivo en función del proyecto en cuestión, estoy buscando el método de "mejores prácticas" para estructurar una solución VS (Visual Studio).

Por favor, siéntase libre de editar esto, comentar lo que piensa que podría ser incorrecto, sugerir alternativas, etc. Me encantaría ver que este Wiki de la Comunidad se convierta en un gran recurso para las personas que recién comienzan con VS Solutions.

Debajo está lo que estoy trabajando para mí ahora (en mi proyecto actual), sin embargo, sé de hecho que hay algunas cosas en el lugar equivocado. En mi caso, estoy construyendo una aplicación web usando MVC 2

Por favor, publique su idea de la estructura de solución definitiva para que podamos tener una idea de la "mejor manera" / "mejor práctica" ( lo que sea que eso signifique exactamente )

ES DECIR:
¿Cómo se divide su DAL (Capa de acceso a datos) / BLL (Business-Logic-Layer)?
¿Pones tu capa de repositorio y capa de servicio dentro de tu BLL? Si está utilizando MVC (Modelo-Vista-Controlador), ¿mantiene sus controladores en la interfaz de usuario en lugar del núcleo?
¿Lanza muchas cosas en sus carpetas de Utilidad / Misceláneas, o las divide aún más?
etc ...

• Mi solución
  • MySolution.Core
    • Autenticación
      • aquí es donde tengo un POCO y un método para ubicar el poco en la sección userData de la cookie de autenticación
    • Base
      • aquí es donde guardo mi BaseController y por BaseGlobal
    • Controladores
      • todos mis controladores (obviamente)
    • Dominio
      • Modelos de base de datos
        • contiene mi archivo L2S .dbml
      • JsonModels
        • modelos utilizados para pasar objetos JSON a la vista
      • Repositorios
      • Servicios
      • ViewModels
    • Extensiones
      • todos los métodos de extensión
    • Filtros
      • Filtros de acción
    • Utilidades
      • Apis
        • todo el código API de terceros entra aquí
      • Insignias
        • el cálculo de la insignia va aquí
      • MailClient
        • envíe texto sin formato o correo electrónico html usando las clases aquí
      • EnrutamientoHelpers
        • contiene una clase para habilitar las rutas en minúsculas
      • también contiene cosas que no sé dónde más poner ... IE: HTMLSanitizer, HtmlHelpers personalizados, UserInfo helper (dirección IP, navegador, etc.), DataConverter, etc.
  • MySolution.UI
    • App_Browsers
    • Bienes
      • Css
      • Imágenes
      • Guiones
    • Puntos de vista
    • Global.asax - hereda de BaseGlobal
    • Web.config

Capturas de pantalla

Por favor, siéntase libre de comentar en consecuencia, o mejor aún, publique su propia versión (respuesta) a continuación. Sé que lo que tengo no es la mejor manera.

Answer 1

Hay posibilidad de mejora.

Cualquiera de mis soluciones tiene 4 partes básicas. La capa de interfaz de usuario, la capa de negocios, la capa de acceso a datos y las utilidades. Cada parte es un proyecto

Mi objetivo final es NUNCA escribir código en más de un lugar, sino reutilizarlo.

La interfaz de usuario y el acceso a los datos son obvios.

Cualquier cosa específica para el proyecto en el que estoy trabajando entra en el proyecto empresarial.

Las utilidades es lo que llamo una biblioteca común. Estas son buenas funciones de ayuda que puedo usar en muchos proyectos. Por ejemplo, una función para ayudar en el registro.

Answer 2

Nice Wiki.

Estoy comenzando un nuevo proyecto, y esta es la estructura con la que comencé.

Sigue las mejores prácticas de Microsoft (negocios, datos, servicios, presentación).

En mi solución:

• Negocio: lógica específica del dominio / proyecto, y más notablemente POCO''s.
• Datos: repositorios. Autoexplicativo.
• Servicios: lógica en la parte superior de los repositorios. Puedo agregar almacenamiento en caché aquí, filtrado, etc. Mi interfaz de usuario se comunica con el repositorio a través de Servicios, no directamente al repositorio. (dependencia uno-a-uno para UI).
• Presentación: aplicación MVC (TBD).

Notarás que también tengo el hábito de anteponer el nombre del ensamblado del proyecto real con el FQN.

Simplemente me gusta su aspecto, además, en el Explorador de objetos todo se ve bien y "como un árbol".

También tengo la costumbre de poner un número delante de la carpeta, por lo que ordena de acuerdo con "qué necesita qué". En otras palabras, todo depende de la capa de negocios (por lo tanto, está en la parte superior), el repositorio solo depende del negocio, los servicios dependen del repositorio y el negocio, la presentación depende de los servicios y el negocio, etc.

Por supuesto, lo anterior es un punto de partida. Todo lo que tengo ahora es un repositorio que devuelve usuarios y servicios que aplican la lógica en la parte superior (filtrado).

Eventualmente tendré más proyectos comerciales, más repositorios (uno para cada área lógica de la aplicación web), más servicios (API externas, integración) y, por supuesto, no tengo nada en la Presentación (estoy haciendo TDD).

También me gusta tener todas las Dependencias en un solo lugar (carpeta del proyecto).

Para las extensiones, tengo una clase (Extensions.cs) para cada proyecto. En otras palabras, estoy "Extendiendo" el repositorio, o "Extendiendo" el servicio al usuario, o "Extendiendo" alguna funcionalidad de UI.

Para proyectos de prueba: tengo proyecto de prueba por proyecto de solución.

Esa es mi Dos Centavos (por lo que vale).

Answer 3

Su estructura de solución / proyecto me parece muy buena. Si nunca has echado un vistazo a S # arp Architecture , es posible que quieras. La principal diferencia entre su estructura y la arquitectura de S # arp es que S # arp divide los Controladores, Servicios y Repositorios en proyectos separados. El principal beneficio de hacer esto es que es más fácil imponer límites en sus dependencias (por ejemplo, no accederá accidentalmente a bibliotecas específicas de acceso a datos desde el código en Core).

Aparte de eso, su estructura se ve muy similar a la que tiendo a usar para mis proyectos. También agrego una carpeta de "Extensiones" para los métodos de extensión, ya que a veces es difícil encontrar un buen lugar para ellos.