Структура решения проекта

Question

Я планирую новый проект, который я разработаю на C++. Мне нужна хорошая структура решения для быстрого обзора проекта. Мой проект - это tcp-сервер. Этот сервер может сохранять файлы и текст от клиента в базе данных или в файловой системе. Сервер также может отправлять файлы и данные из базы данных обратно клиенту. Моя структура должна выглядеть так:

Solution 
- main.cpp 
- DataAccess 
--- Header 
--- Source 
- Business 
--- Header 
--- Source 
- CrossCutting 
--- Header 
--- Source 
- Server 
--- Header 
--- Source 
-------------------------------- 
- External Dependencies 
- Tests (Unit and Integration) 
- Documentation 

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

DataAccess: Вот связь между логикой и данных (базы данных, Ио)

бизнеса: Вот вся логика. Только бизнес имеет доступ к уровню доступа к данным

Сервер: Это мой серверный уровень. Запрос клиента будет обработан. Только уровень сервера имеет доступ к бизнес-уровню.

CrossCutting: Этот слой немного условный. Вот функции, классы, entites и т. Д., Которые понадобятся в нескольких слоях.

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

Answer 1

Что вы думаете об этой структуре решения? Это хорошее начало или мне нужно переработать?

Это хорошее начало; он может использовать некоторую доработку :)

Это прекрасно, если вы думаете об одном проекте. В идеале вы должны разделить это на несколько проектов (как отдельные проекты lib/dll) и иметь основной проект, который содержит ваш main.cpp и запускает приложение/сервер/службу.

Преимущества разделения на нескольких проектов:

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

I wo пакетирования рассмотреть следующие изменения:

корень // корень проекта, источник корневые управления и т.д.

• ExternalDependencies
• Doc
• Src
  • файл решения [связывающиеся с четырех проектов ниже и Испытания]
  • Испытания
    • , содержащий tes т проектов в здесь [каждый в своем собственном каталоге]
    -
  • Применение [каталог]
    • main.cpp
    • главный файл проекта (.vcxproj я думаю)
  • DataAccess
    • заголовки и источники, а не разделенные на отдельные каталоги (поскольку это визуальная студия по умолчанию, и это уменьшит ошибки, вызванные настройками по умолчанию в visual studio)
    • файл проект
  • Бизнес [такой же структура, как DataAccess] ...

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

Примечание: В настоящее время я работаю над относительно большим проектом (~ 180 проектов в решении), используя эту структуру.