Visual Studio 解决方案/项目组织
假设您正在创建一个复杂的后端系统。在系统的某个地方，有一个 IQueue 接口。您计划对队列进行多种实现：
- 原生“内存”
- 数据库（队列在数据库中管理）
- Amazon SQS（在云中使用 Amazon SQS 服务）
- MS/Google/其他队列服务
显然，每种实现将需要它自己的类和实现。每个实现可能需要不同的引用（数据库将需要 DLL 来与相关数据库通信，Amazon SQS 将需要 Amazon AWS DLL 等）。
您将如何针对这种场景组织解决方案？
假设接口和简单的实现位于使用队列的项目中，我看到以下可能的选项：
- 为每个实现单独的 Visual Studio（以及程序集）：
- 优点：更清晰的项目，项目级别的“单一责任”，更容易更新具体实施
- 缺点：许多项目、许多要管理/部署的程序集、Visual Studio 速度较慢 优点
- 单个项目适用于所有“非幼稚”实现：
- 优点/缺点：与第一个选项完全相反。
Let's say that you re creating a complex back-end system. Somewhere in the system, you have an IQueue interface. You are planning to have several implementations for the queue:
- Naive "in-memory"
- Database (where the queue is managed in a database)
- Amazon SQS (using Amazon SQS service in the cloud)
- MS/Google/Other Queuing service
Obviously, each implementation will require it's own class and implementation. Each implementation will probably need different references (Database will require the DLLs to communicate with the relevant database, Amazon SQS will require the Amazon AWS DLLs, etc.)
How would you organize the solution for such a scenario?
Assuming the interface and the naive implementation are places in the project where the queue is used, I see the following possible options:
- Separate Visual Studio (and therefore assembly) for each implementation:
- Pro: Cleaner projects, "single responsibility" at the project level, easier to update specific implementation
- Con: Many projects, many assemblies to manage/deploy, slower Visual Studio
- Single project for all "non-naive" implementations:
- Pro/Con: exact opposite of first option.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，出于您所列出的原因，采用您为每个实现使用单独的 Visual Studio 项目列出的第一条路线是更好的路线。它还具有额外的好处，即能够在进行过程中添加实现，而无需替换二进制文件，这有点不错。
In my opinion, going the first route you listed with a separate Visual Studio project for each implementation is the better one, for the reasons you have listed. It also has the added benefit of being able to add implementations as you go along without have to replace binaries, which is kinda nice.