2

我想知道解决方案中接口子项目的命名约定是什么。我知道接口文件以“I”开头，这也适用于项目吗？

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

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

如果这读得不好，我深表歉意。

4

4 回答 4

3

这是组织多个项目的解决方案的常见模式。然而，有一些争论是否（在某些情况下）值得。

我已经看到使用了一些不同的命名约定：

  1. 公司项目合同
  2. Inc.Project.Contracts
  3. Inc.Project.Interface
  4. Inc.Project （就像一个通用依赖项的基础项目）
  5. Inc.Project.Common
于 2012-07-04T14:18:57.897 回答
1

这是MS使用它的方式<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

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

于 2012-07-04T14:20:42.407 回答
1

我同意 dtryon 在其回答中所写的命名约定。

但不要过度设计解决方案的设计。如果您不需要从多个项目中引用您的界面，我认为将您的界面分离到自己的项目中是没有用的。它增加了复杂性，但好处很少。

接口文件本身也是如此：如果您不打算使用接口类型（而不是实际实现接口的对象的类型）来引用对象实例，那么接口并不是真正有用的。

于 2012-07-04T14:41:44.020 回答
0

我通常遵循...的模式

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

这通常就像我做的那样简单......如果事情更复杂，我可能有一个服务项目或一个业务规则项目或类似性质的东西......我使用接口项目的原因是我想要客户端应用程序完全不了解后端实现；这样，如果我需要更改实现，只要我不更改接口，客户端就不会受到影响（不必更改）......而且，这确实发生了......我之前已经更改过 DBMS，我已经从 DBMS 变成了 API 等等......当最初构建一个应用程序时，额外的抽象层在你需要它之​​前可能看起来有点矫枉过正，那么它就是上帝派来的......

于 2018-12-01T15:37:30.780 回答