我正在计划一个新项目,我将在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:这是逻辑和数据(数据库,io)之间的连接
业务:这是所有的逻辑。只有企业有权访问数据访问层
服务器:这是我的服务器层。客户端请求将在那里处理。只有服务器层可以访问业务层。
横切:这一层有点特殊。这里有函数、类、函数等,它们在几个层中都需要。
我认为其他文件夹应该很清楚。如果没有,请告诉我。您如何看待这种解决方案结构?这是一个好的开始还是我应该返工?
您如何看待这种解决方案结构?这是一个好的开始还是我应该返工?
这是一个好的开始;它可能需要一些返工:)
如果您正在考虑单个项目,这很好。理想情况下,您应该将其拆分为多个项目(作为单独的 lib/dll 项目),并拥有一个包含您的主项目.cpp并启动应用程序/服务器/服务。
拆分为多个项目的优点:
- 每个项目的依赖项划分
- 改进了代码的可测试性
- 强制执行责任分离(比单个项目更多),内部协议的形式化更好(至少在理论上 - 您必须注意正式化您的内部协议)
我会考虑以下更改:
根//项目根、源代码管理根等
- 外部依赖 关系
- 医生
- 来源
- 解决方案文件 [链接到下面的四个项目和测试]
- 测试
- 包含测试项目在这里 [每个在它自己的目录中] -
- 应用 [目录]
- 主.cpp
- 主项目文件(我认为.vcxproj)
- 数据访问
- 标头和源,而不是拆分到单独的目录中(因为这是Visual Studio的默认设置,它将减少Visual Studio中默认设置引起的错误)
- 项目文件
- 业务 [与数据访问结构相同]...
我还会在解决方案文件附近定义一些公共属性页,在其中指定公共生成和临时生成目录,然后跨项目继承这些属性页;这将集中生成工件和二进制文件,并简化常见设置的编辑。
注意:我目前正在使用此结构处理一个相对较大的项目(解决方案中的~180个项目)。