¿Cómo organizas tus proyectos? [cerrado]

¿Tienes algún estilo particular de organización de proyectos?

Por ejemplo, actualmente estoy creando un proyecto para un par de escuelas aquí en Bolivia, así es como lo organicé:

TutoMentor (Solution)
TutoMentor.UI   (Winforms project)
TutoMentor.Data (Class library project)

¿Cómo organiza exactamente su proyecto? ¿Tienes un ejemplo de algo que organizaste y de lo que estás orgulloso? ¿Puedes compartir una captura de pantalla del panel Solución?

En el área de la interfaz de usuario de mi aplicación, tengo problemas para decidir un buen esquema para organizar diferentes formularios y a dónde pertenecen.

Editar:

¿Qué hay de organizar diferentes formas en el proyecto .UI? ¿Dónde / cómo debo agrupar diferentes formas? Ponerlos a todos en el nivel raíz del proyecto es una mala idea.

Al diseñar un proyecto y diseñar la arquitectura, comienzo desde dos direcciones. Primero miro el proyecto que se está diseñando y determino qué problemas de negocios deben resolverse. Miro a las personas que lo usarán y empiezo con un diseño de interfaz de usuario crudo. En este punto, estoy ignorando los datos y solo estoy mirando lo que los usuarios piden y quién los usará.

Una vez que tengo una comprensión básica de lo que están pidiendo, determino cuáles son los datos centrales que manipularán y comienzo un diseño de base de datos básico para esos datos. Luego empiezo a hacer preguntas para definir las reglas comerciales que rodean los datos.

Al comenzar desde ambos extremos de forma independiente, puedo diseñar un proyecto de una manera que combine los dos extremos. Siempre trato de mantener los diseños separados por el mayor tiempo posible antes de fusionarlos, pero tengo en cuenta los requisitos de cada uno a medida que avanzo.

Una vez que tengo una buena comprensión sólida de cada extremo del problema, comienzo a diseñar la estructura del proyecto que se creará para resolver el problema.

Una vez que se crea el diseño básico de la solución del proyecto, miro la funcionalidad del proyecto y configuro un conjunto base de espacios de nombres que se utilizan según el tipo de trabajo que se realiza. Esto puede ser cosas como cuenta, carrito de compras, encuestas, etc.

Aquí está el diseño de la solución básica con la que siempre empiezo. A medida que los proyectos se definen mejor, lo refino para satisfacer las necesidades específicas de cada proyecto. Algunas áreas pueden fusionarse con otras y puedo agregar algunas especiales según sea necesario.

SolutionName

.ProjectNameDocuments
    For large projects there are certain documents that need to be kept with
    it. For this I actually create a separate project or folder within the 
    solution to hold them.
.ProjectNameUnitTest
    Unit testing always depends on the project - sometimes it is just really 
    basic to catch edge cases and sometimes it is set up for full code 
    coverage.  I have recently added graphical unit testing to the arsenal.
.ProjectNameInstaller
    Some projects have specific installation requirements that need to be 
    handled at a project level.
.ProjectNameClassLibrary
    If there is a need for web services, APIs, DLLs or such.
.ProjectNameScripts (**Added 2/29/2012**)
    I am adding this because I just found a need for one in my current project.  
    This project holds the following types of scripts: SQL (Tables, procs, 
    views), SQL Data update scripts, VBScripts, etc.
.ProjectName
    .DataRepository 
        Contains base data classes and database communication.  Sometimes 
        also hold a directory that contains any SQL procs or other specific 
        code.  
    .DataClasses
        Contains the base classes, structs, and enums that are used in the 
        project.  These may be related to but not necessarily be connected
        to the ones in the data repository.
    .Services 
        Performs all CRUD actions with the Data, done in a way that the 
        repository can be changed out with no need to rewrite any higher 
        level code.
    .Business
        Performs any data calculations or business level data validation,
        does most interaction with the Service layer.
    .Helpers
        I always create a code module that contains helper classes.  These 
        may be extensions on system items, standard validation tools, 
        regular expressions or custom-built items.  
    .UserInterface
        The user interface is built to display and manipulate the data.  
        UI Forms always get organized by functional unit namespace with 
        additional folders for shared forms and custom controls.

Me gusta dividir mis proyectos en capas

De esa manera, es más fácil administrar las dependencias cíclicas. Puedo garantizar que ningún proyecto está importando el proyecto Ver (capa) por error, por ejemplo. También tiendo a romper mis capas en subcapas. Entonces, todas mis soluciones tienen una lista de proyectos como este:

• Producto.
• Modelo del Producto
• Presentador de producto
• Producto Persistencia
• Product.UI
• Producto Validación
• Informe del producto
• Producto Web

Son los "bloques de construcción" más grandes de mi aplicación. Luego, dentro de cada proyecto, lo organizo en espacios de nombres de manera más lógica, pero varía mucho. Para la interfaz de usuario al crear muchas formas, intento pensar en una división espacial y luego crear espacios de nombres para cada "espacio". Digamos que hay un montón de preferencias de usuario, controles y formularios de usuario, tendría un espacio de nombre llamado UserPreferences para ellos, y así sucesivamente.

Organizando proyectos

Normalmente trato de dividir mis proyectos por espacio de nombres, como usted dice. Cada nivel de una aplicación o componente es su propio proyecto. Cuando se trata de cómo decido cómo dividir mi solución en proyectos, me concentro en la reutilización y las dependencias de esos proyectos. Pienso en cómo otros miembros de mi equipo utilizarán el proyecto, y si otros proyectos que creamos en el futuro pueden beneficiarse del uso de algún componente del sistema.

Por ejemplo, a veces, solo tener este proyecto, que tiene un conjunto completo de marcos (correo electrónico, registro, etc.) es suficiente:

MyCompany.Frameworks

Otras veces, es posible que desee dividir los marcos en pedazos, para que puedan importarse individualmente:

MyCompany.Frameworks.Networking
MyCompany.Frameworks.Logging
MyCompany.Frameworks.SomeLOBFramework

Organizando formas

Organizar formularios bajo un proyecto de UI realmente se transformará a medida que su proyecto se expanda.

• Pequeño : una carpeta de formularios simple podría ser suficiente para un proyecto muy pequeño. A veces, puedes modificar las estructuras de ingeniería al igual que los espacios de nombres y hacer las cosas mucho más complicadas de lo que deberían ser.

• Mediano a grande : aquí, generalmente comienzo a dividir mis formularios en áreas funcionales. Si tengo una parte de mi aplicación que tiene 3 formularios para administrar un usuario y algunos que realizan un seguimiento de los juegos y puntajes de fútbol, ​​entonces tendré un área de Formularios> Usuario y un área de Formularios> Juegos o algo así. Realmente depende del resto del proyecto, cuántas formas tengo en cuanto a qué tan fino lo separo.

Recuerde, al final del día, los espacios de nombres y las carpetas están ahí para ayudarlo a organizarse y encontrar las cosas más rápido.

Realmente, depende de tu equipo, tus proyectos y lo que sea más fácil para ti. Sugeriría que, en general, realice proyectos separados para cada capa / componente de su sistema, pero siempre hay excepciones.

Para obtener orientación sobre la arquitectura del sistema, consulte el sitio de Patrones y prácticas de Microsoft.

Cuando escribo código en .NET, existe una clara tendencia a tener grupos de funcionalidades relacionadas. Cada uno de los cuales puede tener algunos subconjuntos de los mismos. Me gusta separar físicamente a los grupos principales, uno de estos por proyecto VS. Luego subdivido lógicamente usando ensamblajes. Siguiendo este patrón, uno de mis proyectos actuales se ve así:

• Wadmt (solución)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Servicios Wadmt.
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

Espero que te sea útil. Los niveles de separación me tomaron un tiempo para darme cuenta.

Es bueno tener un plan para organizar sus soluciones, y hay varias formas de hacerlo. Tenemos algunas funciones que se comparten en varios proyectos, lo que también proporciona coherencia para nuestros usuarios. La organización del proyecto depende de lo que estamos haciendo. En esencia, tendremos:

Company (solution)
  Company.Common (shared library)
  Company.Project (Main application UI)
  Company.Project.UnitTests (Unit tests for all project modules)
  Company.Project.IntegrationTests (integration tests for all project modules)
  Company.Project.AutomationTests (tests that invoke the UI)

A partir de ahí, realmente depende de la configuración. Si tenemos una aplicación cliente y un front-end web (útil para recopilar resultados de uso en el aula u otra investigación), necesitamos un proyecto que tenga el código comúnmente compartido (es decir, los objetos de datos que se serializarán).

  Company.Project.Model (ORM and business logic layer)
  Company.Project.Webapp (Web frontend/web service layer)
  Company.Project.WebClient (client code for web services)

Se pueden agregar otros subproyectos según sea necesario. Como dije, realmente depende del proyecto. Algunos proyectos son realmente simples y solo necesitan elementos centrales. Intentamos luchar contra la separación arbitraria de proyectos, por lo que dividir por capas realmente tiene sentido. Las capas se definen por lo que debe compartirse entre proyectos, soluciones o lo que debe ser complementos / extensiones.

Es interesante que tanta gente no considere DRY aquí. Sucedió algunas veces en mi vida que los desarrolladores crearon estructuras de directorios que no pudieron construir debido a eso. ¡Mantenga el nombre del proyecto fuera de la solución y los directorios del proyecto!

Así que aquí está mi camino:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  

Cuando diseño mi aplicación, siempre la veo como módulos con algunas dependencias entre ellos. Cuando tengo un diseño en mente, entonces uso una estrategia de abajo hacia arriba para desarrollarlo. Desarrollo cada módulo y luego los hago trabajar juntos.

Bueno, esos módulos son proyectos bajo mi solución (generalmente bibliotecas de clases ). Cada módulo tiene un espacio de nombres diferente y su propio diseño (que contiene clases , etc.).

Uno de esos módulos es la GUI ( interfaz gráfica de usuario ).

También siempre uso una herramienta de control de revisiones para rastrear los cambios en cada proyecto. Sugiero a Git . Es de código abierto, distribuido y de uso gratuito.

Cada vez que comienzo un nuevo proyecto obtengo una amplia especificación de lo que se supone que debe hacer. Tener este aporte me ayuda al proporcionarme un contexto, por lo tanto, sigo adelante y pienso en el mejor (o más apropiado) método para lograr los objetivos del proyecto. En este punto, empiezo a pensar en qué patrones de diseño pueden ayudarme a proporcionar la solución deseada. Aquí es donde comienzo a organizar el proyecto, teniendo en cuenta los patrones de diseño que adoptaré para el proyecto.

Un par de ejemplos:

1. Si el proyecto solo se refiere a construir pantallas de datos de entrada. Lo más probable es que use un patrón MVC.
2. Si el proyecto se va a utilizar como una interfaz de usuario de servicio pesado que admite la mayoría de las plataformas múltiples, un patrón de diseño MVVM se vuelve útil.

Tenga en cuenta que cada uno de estos le obligará a organizar su proyecto de una manera específica.

Aquí hay algunas lecturas para ti:

Patrones de diseño neto .

Patrones de diseño .

Diseño orientado a objetos .

Espero que esto ayude.