Каков наилучший способ структурировать проект?[закрыто]

Question

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

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

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

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

В стандартном 3-уровневом приложении is должно нравиться что-то вроде :

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

Есть еще какие - нибудь идеи ?

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

Спасибо!

Answer 1

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

Компания.Имяпроекта.Данные (т.е.AdventureWorks.Менеджер заказов.Данные)

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

Компания.Имяпроекта.Объектная модель (т.е.AdventureWorks.Менеджер заказов.Объектная модель)

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

Компания.Название проекта.Презентация (т.е.AdventureWorks.Менеджер заказов.Презентация)

Answer 2

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

Answer 3

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

Answer 4

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

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

Для получения более подробной информации по этой большой теме я настоятельно рекомендую прочитать Domain Driven Design От Eric Evans и Applying Domain-Driven Design and Patterns От Jimmmy Nilsson.

Answer 5

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

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

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

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

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

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

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

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

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