Как лучше структурировать проект?

Мне было интересно, как я должен структурировать свои проекты.

У нас есть несколько проектов, которые (повторно) используются в других проектах.

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

Что мне действительно нужно знать, так это то, как структурировать проект такого типа, как его лучше всего назвать?

В стандартном трехуровневом приложении это должно выглядеть примерно так:

  1. DAL, уровень доступа к данным, данные...
  2. Модель, БизнесОбъект, БОЛ...
  3. Пользовательский интерфейс, вид, ...

Любые другие идеи?

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

Спасибо!


architecture n-tier-architecture layered projects
person Melursus    schedule 21.02.2009    source источник

Ответы (5)


arrow_upward
1
arrow_downward

Для уровня данных я обычно использую:

Company.ProjectName.Data (например, AdventureWorks.OrderManager.Data)

Для бизнес-уровня я предпочитаю что-то вроде «ObjectModel» (я использовал «Business» или «BusinessLogic», но это область, где данные объединяются в объекты/классы, так почему бы не назвать ее так?).

Company.ProjectName.ObjectModel (например, AdventureWorks.OrderManager.ObjectModel)

Что касается пользовательского интерфейса, мне нравится старый добрый «пользовательский интерфейс» или «презентация»...

Company.ProjectName.Presentation (например, AdventureWorks.OrderManager.Presentation)

person Brandon    schedule 21.02.2009

arrow_upward
2
arrow_downward

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

person Andrew Bullock    schedule 21.02.2009

arrow_upward
1
arrow_downward

В основном я использую многоуровневую архитектуру в соответствии с рекомендациями Microsoft Patterns & Practices Архитектура приложений для .NET: Разработка приложений и служб. Документ описывает архитектуру и технологии .NET для ее реализации.

alt text

person Canavar    schedule 21.02.2009

arrow_upward
0
arrow_downward

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

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

Чтобы лучше понять эту большую тему, я настоятельно рекомендую прочитать Domain Driven Design из Eric Evans и Applying Domain-Driven Design and Patterns из Jimmmy Nilsson.

person prinzdezibel    schedule 21.02.2009

arrow_upward
0
arrow_downward

В настоящее время я работаю над интерфейсным веб-приложением с трехуровневой архитектурой:

  • Клиентский уровень (браузер)
  • Уровень приложений (сервер приложений Java EE, на котором будет жить приложение)
  • Бэкэнд-уровень (мэйнфреймы и устаревшие приложения, различные базы данных)

Он имеет многоуровневую архитектуру, а уровни на уровне приложений:

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

Это всего лишь пример структуры проекта, и конечный результат будет зависеть от типа приложения. Вы можете прочитать больше в мой ответ на этот вопрос о разделении и стратегии именования пакетов.

Вы можете добавлять/заменять/удалять слои по своему усмотрению. Например, в SOA вы можете разместить уровень веб-службы поверх уровня приложения или уровня службы, чтобы ESB (корпоративная служебная шина) могла подключаться к вашему приложению или службам. Если что-то из этого невозможно или кажется очень сложным, у вас нет оптимальной архитектуры и дизайна.

Когда вы думаете о структуре вашего проекта и допускаете сценарии, подобные приведенному выше, некоторые важные свойства ваших модулей и компонентов, которые вам нужны:

  • Тестируемость
  • Возможность повторного использования
  • Ремонтопригодность

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

person eljenso    schedule 21.02.2009