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

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

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

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

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

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


Edit:

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

132 голоса | спросил Sergio 27 Jam1000000amThu, 27 Jan 2011 06:55:05 +030011 2011, 06:55:05

8 ответов


93

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

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

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

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

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

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

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.
ответил Amy Patterson 4 FebruaryEurope/MoscowbFri, 04 Feb 2011 18:52:35 +0300000000pmFri, 04 Feb 2011 18:52:35 +030011 2011, 18:52:35
61

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

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

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

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

ответил Alex 1 FebruaryEurope/MoscowbTue, 01 Feb 2011 00:31:33 +0300000000amTue, 01 Feb 2011 00:31:33 +030011 2011, 00:31:33
18

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

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

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

MyCompany.Frameworks

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

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

Организация форм

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

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

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

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


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

Инструкции по архитектуре системы см. в сайте шаблонов и практик Microsoft .

ответил Ryan Hayes 27 Jam1000000amThu, 27 Jan 2011 07:37:46 +030011 2011, 07:37:46
9

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

  • Wadmt (решение)
    • 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

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

ответил Grant Palin 1 FebruaryEurope/MoscowbTue, 01 Feb 2011 05:34:03 +0300000000amTue, 01 Feb 2011 05:34:03 +030011 2011, 05:34:03
6

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

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)

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

ответил Berin Loritsch 1 FebruaryEurope/MoscowbTue, 01 Feb 2011 05:35:14 +0300000000amTue, 01 Feb 2011 05:35:14 +030011 2011, 05:35:14
6

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

Итак, вот мой путь:

{drive}:\{customer}\{apps|libs|tools}\{project}
  - cer
  - res
  - src
   - Common
   - Data
   - UI
   - Logic
   - Logic._Tests  
ответил Daniel Fisher lennybacon 14 FebruaryEurope/MoscowbMon, 14 Feb 2011 16:40:37 +0300000000pmMon, 14 Feb 2011 16:40:37 +030011 2011, 16:40:37
2

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

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

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

Я также всегда использую инструмент Revision Control для отслеживания изменения в каждом проекте. Я предлагаю Git . Это open source, распространяется и свободно используется.

ответил Oscar Mederos 27 Jam1000000amThu, 27 Jan 2011 10:08:59 +030011 2011, 10:08:59
1

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

Несколько примеров:

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

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

Вот вам кое-что для чтения:

шаблоны проектирования. .

шаблоны проектирования .

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

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

ответил El Padrino 1 FebruaryEurope/MoscowbWed, 01 Feb 2012 15:57:02 +0400000000pmWed, 01 Feb 2012 15:57:02 +040012 2012, 15:57:02

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132