¿Cómo organiza sus proyectos? [cerrado]

135

¿Tiene 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 organizas exactamente tu proyecto? ¿Tiene un ejemplo de algo que organizó y está orgulloso? ¿Puede 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 las diferentes formas y 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.

    
pregunta 27.01.2011 - 04:55
fuente

8 respuestas

94

Al diseñar un proyecto y diseñar la arquitectura, comienzo desde dos direcciones. Primero observo el proyecto que se está diseñando y determine cuáles son los problemas de negocios que deben resolverse. Miro a la gente que lo usará y comienzo con un diseño de IU en bruto. En este punto, estoy ignorando los datos y solo miro lo que piden los usuarios 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 estarán manipulando y comenzar un diseño básico de la base de datos para esos datos. Luego comienzo a hacer preguntas para definir las reglas de negocio que rodean los datos.

Partiendo de ambos extremos de forma independiente, puedo diseñar un proyecto de forma que se fusionen los dos extremos. Siempre trato de mantener los diseños separados por el mayor tiempo posible antes de fusionarlos, pero tenga 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, observo la funcionalidad del proyecto y configuro un conjunto básico de espacios de nombres que se utilizan según el tipo de trabajo que se realice. Esto puede ser cosas como Cuenta, Carrito de compras, Encuestas, etc.

Aquí está el diseño de la solución básica con el que siempre comienzo. 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 some times it is just really 
    basic to catch edge cases and some times it is set up for full code 
    coverage.  Recently have 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, 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 an 
        additional folder for shard forms and one for custom controls.
    
respondido por el Amy Patterson 04.02.2011 - 16:52
fuente
61

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. Así que todas mis soluciones tienen una lista de proyectos como este:

  • Product.Core
  • Modelo de producto
  • Product.Presenter
  • Product.Persistence
  • Product.UI
  • Product.Validation
  • Informe de producto
  • Product.Web

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

    
respondido por el Alex 31.01.2011 - 22:31
fuente
18

Organizando Proyectos

Por lo general, 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 reusabilidad y dependencias de esos proyectos. Pienso en cómo otros miembros de mi equipo usarán el proyecto, y si otros proyectos que creamos en el futuro puedan beneficiarse del uso de algún componente del sistema.

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

MyCompany.Frameworks

Otras veces, es posible que desee desglosar los marcos para que se puedan importar individualmente:

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

Organizar formularios

Organizar formularios en un proyecto de IU realmente se modificará a medida que tu proyecto se expanda.

  • Pequeño : una simple carpeta de Formularios podría ser suficiente para un proyecto muy pequeño. A veces se pueden sobregrabar estructuras como los espacios de nombres y hacer las cosas 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 hacen un seguimiento de los juegos de fútbol y las puntuaciones, entonces tendré un Formularios > Área de usuario y un Formularios > Área de juegos o algo así. Realmente depende del resto del proyecto, de cuántas formas tengo en cuanto a la forma en que lo dividí.

Recuerda, al final del día, los espacios de nombres y las carpetas están ahí para ayudarte a organizar 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 sitio de patrones y prácticas de Microsoft

    
respondido por el Ryan Hayes 27.01.2011 - 05:37
fuente
9

Cuando escribo código en .NET, hay 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 los grupos principales, uno de estos por proyecto VS. Luego subdivido más 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
    • Wadmt.Services
    • Pruebas Wadmt.
      • Wadmt.Tests.Common
      • Wadmt.Tests.Domain
      • Wadmt.Tests.Services
      • Wadmt.Tests.Integration
    • Wadmt.Web

Esperemos que te sea de utilidad. Los niveles de separación me tomaron un tiempo para descifrarlos.

    
respondido por el Grant Palin 01.02.2011 - 03:34
fuente
6

Es bueno tener un plan para organizar sus soluciones, y hay varias maneras de hacerlo. Tenemos algunas funcionalidades que se comparten en múltiples proyectos, lo que también proporciona consistencia para nuestros usuarios. La organización del proyecto depende de lo que estamos haciendo. En su núcleo 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 combatir la separación arbitraria de proyectos, por lo que dividir por capas realmente tiene sentido. Las capas se definen según lo que se debe compartir entre proyectos, soluciones o lo que necesitan ser complementos / extensiones.

    
respondido por el Berin Loritsch 01.02.2011 - 03:35
fuente
6

Es interesante que tantas personas no consideren SECO aquí. Ocurrió varias 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 los directorios de soluciones y proyectos!

Así que aquí está mi camino:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  
    
respondido por el Daniel Fisher lennybacon 14.02.2011 - 14:40
fuente
2

Cuando estoy diseñando mi aplicación, siempre la veo como módulos con algunas dependencias entre ellos. Cuando tengo un diseño en mente, luego 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 en 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 Control de revisión para rastrear los cambios en cada proyecto. Sugiero Git . Es de código abierto, distribuido y de uso gratuito.

    
respondido por el Oscar Mederos 27.01.2011 - 08:08
fuente
1

Cada vez que empiezo en un nuevo proyecto obtengo una especificación amplia de lo que se supone que haga. Contar con esta información me ayuda proporcionándome un contexto, por lo tanto, sigo adelante y creo que el mejor (o el más apropiado) método para lograr los objetivos del proyecto. En este punto, empiezo a pensar en qué patrones de diseño pueden proporcionarme la solución deseada. Aquí es donde empiezo 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 la construcción de pantallas de datos de entrada. Probablemente yo usaría un patrón MVC.
  2. Si el proyecto se va a utilizar como una interfaz de usuario de servicio pesado que la mayoría de las plataformas soporta, el patrón de diseño MVVM se vuelve útil.

Tenga en cuenta que todo esto lo obligará a organizar su proyecto de una manera específica.

Aquí hay una lectura para ti:

.Net Design Patterns .

Patrones de diseño .

Diseño orientado a objetos .

Espero que esto ayude.

    
respondido por el El Padrino 01.02.2012 - 12:57
fuente

Lea otras preguntas en las etiquetas