Как вы организовываете свои проекты? [закрыто]

У вас есть особый стиль организации проектов?

Например, в настоящее время я создаю проект для пары школ здесь, в Боливии, вот как я его организовал:

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

Как именно вы организуете свой проект? У вас есть пример того, что вы организовали и чем гордитесь? Можете ли вы поделиться снимком экрана панели Solution?

В области пользовательского интерфейса моего приложения у меня возникают проблемы с выбором хорошей схемы для организации различных форм и их принадлежности.

Редактировать:

А как насчет организации различных форм в проекте .UI? Где / как мне группировать разные формы? Поместить их все на корневой уровень проекта - плохая идея.

При разработке проекта и планировании архитектуры я начинаю с двух направлений. Сначала я смотрю на проектируемый проект и определяю, какие бизнес-проблемы необходимо решить. Я смотрю на людей, которые будут его использовать, и начну с грубого дизайна пользовательского интерфейса. На данный момент я игнорирую данные и просто смотрю на то, что просят пользователи и кто будет их использовать.

Получив базовое понимание того, о чем они просят, я определяю основные данные, которыми они будут манипулировать, и начинаю базовый макет базы данных для этих данных. Затем я начинаю задавать вопросы, чтобы определить бизнес-правила, окружающие данные.

Начав с обоих концов независимо, я могу планировать проект таким образом, чтобы соединить два конца вместе. Я всегда стараюсь как можно дольше сохранять отдельные проекты, прежде чем объединять их вместе, но при этом буду помнить о требованиях каждого.

Когда у меня есть хорошее понимание каждого конца проблемы, я начинаю планировать структуру проекта, которая будет создана для решения проблемы.

После создания базовой схемы решения проекта я смотрю на функциональность проекта и настраиваю базовый набор пространств имен, которые используются в зависимости от типа выполняемой работы. Это могут быть такие как аккаунт, корзина покупок, опросы и т. Д.

Вот базовая схема решения, с которой я всегда начинаю. По мере того, как проекты становятся более определенными, я уточняю их для удовлетворения конкретных потребностей каждого проекта. Некоторые области могут быть объединены с другими, и я могу добавить несколько специальных по мере необходимости.

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.

Мне нравится делить свои проекты на слои

Таким образом, легче управлять циклическими зависимостями. Например, я могу гарантировать, что ни один проект не импортирует проект View (layer) по ошибке. Я также склонен разбивать свои слои на подслои. Так что все мои решения имеют список таких проектов:

• Product.Core
• Product.Model
• Product.Presenter
• Product.Persistence
• Product.UI
• Product.Validation
• Product.Report
• Product.Web

Они являются большими «строительными блоками» моего приложения. Затем внутри каждого проекта я организую в пространствах имен более логично, но это сильно варьируется. Что касается пользовательского интерфейса при создании множества форм, я стараюсь мыслить пространственно, а затем создавать пространства имен для каждого «пробела». Допустим, есть группа пользовательских элементов управления и форм пользовательских настроек, у меня будет пространство имен с именем UserPreferences для них и так далее.

Организация проектов

Как правило, я стараюсь разделить свои проекты по пространству имен, как вы говорите. Каждый уровень приложения или компонента - это собственный проект. Когда дело доходит до того, как я решаю, как разбить свое решение на проекты, я концентрируюсь на возможности повторного использования и зависимости этих проектов. Я думаю о том, как другие члены моей команды будут использовать этот проект, и если другие проекты, которые мы создаем в будущем, могут извлечь выгоду из использования какого-либо компонента системы.

Например, иногда достаточно иметь этот проект, который имеет полный набор фреймворков (электронная почта, ведение журналов и т. Д.):

MyCompany.Frameworks

В других случаях я могу разбить фреймворки на части, чтобы их можно было импортировать по отдельности:

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

Организационные формы

Организация форм в рамках проекта пользовательского интерфейса действительно изменится по мере расширения вашего проекта.

• Маленький - простой папки Forms может быть достаточно для очень маленького проекта. Иногда вы можете перепроектировать структуры так же, как вы можете использовать пространства имен и сделать вещи намного сложнее, чем они должны быть.

• От среднего к большому - здесь я обычно начинаю делить свои формы на функциональные области. Если у меня есть одна часть моего приложения, в которой есть 3 формы для управления пользователем, и одна, которая отслеживает футбольные игры и результаты матчей, тогда у меня будут формы> Пользовательская область и Форма> Игры или что-то в этом роде. Это действительно зависит от остальной части проекта, от того, сколько форм у меня есть, насколько я детализирован, разбиваю его.

Помните, что в конце дня пространства имен и папки только для того, чтобы помочь вам упорядочить и быстрее находить вещи.

На самом деле, это зависит от вашей команды, ваших проектов и того, что для вас проще. Я бы предложил, чтобы вы делали отдельные проекты для каждого слоя / компонента вашей системы, но всегда есть исключения.

Руководство по архитектуре системы см. На сайте Microsoft Patterns and Practices.

Когда я пишу код в .NET, есть четкая тенденция иметь кластеры связанных функций. Каждый из которых может иметь несколько подмножеств одинаковых. Мне нравится выделять основные группы физически - одна из них на проект VS. Затем я далее делю логически, используя сборки. Следуя этой схеме, один из моих текущих проектов выглядит так:

• Вадмт (решение)
  • Wadmt.Common
  • Wadmt.Data
    • Wadmt.Data.MySql
    • Wadmt.Data.SqlServer
    • Wadmt.Data.Oracle
  • Wadmt.Domain
  • Wadmt.Services
  • Wadmt.Tests
    • Wadmt.Tests.Common
    • Wadmt.Tests.Domain
    • Wadmt.Tests.Services
    • Wadmt.Tests.Integration
  • Wadmt.Web

Надеюсь, это полезно для вас. Уровни разделения заняли у меня некоторое время, чтобы выяснить.

Хорошо иметь план организации ваших решений, и есть несколько способов сделать это. У нас есть некоторые функции, которые совместно используются несколькими проектами, что также обеспечивает согласованность для наших пользователей. Организация проекта зависит от того, что мы делаем. По своей сути мы будем иметь:

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)

Оттуда это действительно зависит от настройки. Если у нас есть и клиентское приложение, и веб-интерфейс (полезный для сбора результатов использования в классе или других исследованиях), нам нужен проект, имеющий общий код (т. Е. Объекты данных, которые будут сериализованы).

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

Другие подпроекты могут быть добавлены по мере необходимости. Как я уже сказал, это действительно зависит от проекта. Некоторые проекты действительно просты и требуют только основных элементов. Мы пытаемся бороться с произвольным разделением проекта, поэтому разделение по слоям действительно имеет смысл. Слои определяются тем, что нужно совместно использовать в проектах, решениях или в качестве плагинов / расширений.

Интересно, что так много людей здесь не считают СУХОЙ. Несколько раз в моей жизни разработчики создавали структуры каталогов, которые из-за этого не могли создавать. Не включайте название проекта в каталоги решений и проектов!

Так вот мой путь:

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

Когда я проектирую свое приложение, я всегда вижу его как модули с некоторыми зависимостями между ними. Когда я имею в виду дизайн, я использую восходящую стратегию для его разработки. Я разрабатываю каждый модуль, а затем заставляю их работать вместе.

Ну, эти модули являются проектами в моем решении (обычно это библиотеки классов ). Каждый модуль имеет свое пространство имен и свой собственный дизайн (содержащий классы и т. Д.).

Одним из таких модулей является GUI ( графический интерфейс пользователя ).

Я также всегда использую инструмент контроля версий для отслеживания изменений в каждом проекте. Я предлагаю Git . Это с открытым исходным кодом, распространяется и бесплатное использование.

Каждый раз, когда я начинаю новый проект, я получаю широкую спецификацию того, что он должен делать. Наличие этого вклада помогает мне, предоставляя мне контекст, поэтому я иду вперед и думаю, что лучший (или наиболее подходящий) метод для достижения целей проекта. В этот момент я начинаю думать, какие шаблоны проектирования могут помочь мне найти намеченное решение. Здесь я начинаю организовывать проект с учетом шаблонов проектирования, которые я приму для проекта.

Пара примеров:

1. Если проект относится только к созданию экранов ввода данных. Скорее всего, я бы использовал шаблон MVC.
2. Если проект будет использоваться в качестве сверхпрочного пользовательского интерфейса, который в большинстве своем поддерживает несколько платформ, полезен шаблон проектирования MVVM.

Имейте в виду, что каждый из этих факторов заставит вас организовать свой проект определенным образом.

Вот некоторые чтения для вас:

Шаблоны .Net Design .

Шаблоны дизайна .

Объектно-ориентированный дизайн .

Надеюсь это поможет.