我想知道解决方案中的Interface子项目的命名约定是什么。我知道接口文件以“I”开头，这是否也适用于项目？
我已将接口分成单独的项目以保持解决方案的有序性，而不是在项目中创建将实现接口的接口文件。
所有文件和项目都包含在一个解决方案中。
如果这不好读，我道歉。
答案 0 :(得分：2)
这是组织许多项目解决方案的常见模式。但是，对于（在某些情况下）是否值得它存在争议。
我见过几种不同的命名约定：
答案 1 :(得分：1)
这是MS使用它的方式<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
例如，Microsoft.WindowsMobile.DirectX.请参阅链接http://msdn.microsoft.com/en-us/library/ms229026.aspx
答案 2 :(得分：1)
我同意dtryon在其答案中所写的命名惯例。
但是不要过度设计解决方案的设计。如果您不需要从多个项目引用您的界面，我不认为在自己的项目中分离您的界面是有用的。它增加了复杂性，但收效甚微。
接口文件本身也是如此：如果您不打算使用接口类型引用对象实例（而不是实际实现接口的对象的类型），那么该接口实际上并没有用。
答案 3 :(得分：0)
我通常遵循...的模式
通常就像我做的那样简单...如果事情更复杂，我可能有一个服务项目或业务规则项目或类似性质的东西...我使用接口项目的原因是我想要客户端应用程序完全不了解后端实现；这样，如果我需要更改实现，只要我不更改接口，客户端就不会受到影响（不必更改）。而且，这确实发生了……我之前更改了DBMS，已经从DBMS更改为API，等等。。。最初构建应用程序时，多余的抽象层在您需要之前似乎有点过头了，那真是令人发指...