一个解决方案中有多个项目：接口命名规范

Question

我想知道在解决方案中，接口子项目的命名规范应该是什么。我知道接口文件以"I"开头，但这是否也适用于项目？

我将接口单独分成一个项目来保持解决方案的组织性，而不是在实现接口的项目中创建接口文件。

所有文件和项目都包含在一个解决方案中。

如果阅读起来不太流畅，请谅解。

- Stefan McCallum

Answer 1

这是一种常见的组织包含多个项目的解决方案的模式。然而，有些人对于是否值得使用这种模式存在争议。

我见过几种不同的命名约定：

1. 公司简称.项目名称.合同
2. 公司简称.项目名称.合同集合
3. 公司简称.项目名称.接口
4. 公司简称.项目名称（作为一个公共依赖的基本项目）
5. 公司简称.项目名称.通用

- Davin Tryon

Answer 2

这是微软使用的方式 <公司>.(<产品>|<技术>)[.<特性>][.<子命名空间>]

例如，Microsoft.WindowsMobile.DirectX. 参见链接 http://msdn.microsoft.com/en-us/library/ms229026.aspx

- HatSoft

Answer 3

我同意dtryon在回答中提到的命名约定。

但是不要过度设计你的解决方案。如果你不需要从多个项目引用你的接口，我认为将接口分离到自己的项目中并没有什么用处。这会增加复杂性，但好处很少。

对于接口文件本身也是一样的：如果你不打算使用接口类型来引用对象实例（而不是实际实现接口的对象类型），那么接口就没有什么用处。

- ken2k

Answer 4

我通常遵循以下模式...

1. MyAppSolution - 空解决方案
2. MyApp.App - 面向客户端的应用程序
3. MyApp.Adapters - 包含接口的项目
4. MyApp.DAL - 数据访问层

这通常是我所做的最简单的事情...如果事情更加复杂，我可能会有一个服务项目或业务规则项目或类似的东西...我使用接口项目的原因是我希望客户端应用程序完全不知道后端实现；这样，如果我需要更改实现，客户端不受影响（不必更改），只要我不更改接口...而且，这确实发生过...我以前曾经更改过DBMS，我已经从DBMS更改为API等...在最初构建应用程序时，额外的抽象层可能看起来像杀鸡焉用牛刀，直到你需要它，那么它就是上天赐予的礼物...

- Michael Qualls

---

MyApp前缀的好处是什么？从解决方案名称中不清楚它是什么类型的应用程序？ - Muflix