2014-12-03 107 views
0

我正在开发一个遵循3层体系结构并且其数据访问层(DAL)由其他人编写的项目。我检查了代码,发现他使用两个类库和数据访问层(DAL)中的一个接口连接到数据库。界面是IDBManager和类库是DBManagerFactoryDBManager在项目中声明命名空间外的枚举

类DBManagerFactory,他宣称这样一个枚举的DataProvider:

using System; 
using System.Data; 
using System.Data.Odbc; 
using System.Data.SqlClient; 
using System.Data.OleDb; 

public enum DataProvider 
{ 
    Oracle, SqlServer, OleDb, Odbc 
} 

namespace DataAccessLayer 
{ 
    public sealed class DBManagerFactory 
    { 
     private DBManagerFactory() { } 

和接口IDBManager,他用这样的枚举:

using System; 
using System.Data; 
using System.Data.Odbc; 
using System.Data.SqlClient; 
using System.Data.OleDb; 

namespace DataAccessLayer 
{ 
    public interface IDBManager 
    { 
     DataProvider ProviderType 
     { 
      get; 
      set; 
     } 

     string ConnectionString 
     { 
      get; 
      set; 
     } 

所以,我的问题是,在命名空间之外声明枚举是一种好方法还是坏方法?我认为应该在命名空间内声明枚举,并通过命名空间在另一个类或其他项目中使用枚举。请告知标准方法。

+0

将这些类型打包到有意义的命名空间中是一种很好的做法,这样我们就可以有一个清晰的分离和更好的想法。但是,如果这些类型是常见的,我们不希望类型转换,那么你可能会把它们放在命名空间之外。 – 2014-12-03 08:21:27

+0

@SivaGopal - 我无需使用名称空间就可以看到枚举的唯一好处是我们可以在其他类中使用它,而无需添加名称空间的名称。 – 2014-12-03 09:41:27

+1

Shory版本:是的,它应该在命名空间内;污染全球命名空间的形式很差;它也存在导致冲突的真实风险。 – 2014-12-04 11:08:01

回答

0

对于编译器来说,只要没有名称冲突,它无关紧要。

如果在单独的名称空间中定义,则两种类型可以具有相同的名称。 “空白”名字空间也可以被认为是一个名字空间。

假设您有两种类型,My.Namespace.DataProviderYour.Namespace.DataProvider。如果你想同时使用,你必须区分一个从其他:

private My.Namepspace.DataProvider myDataProvider; 
private Your.Namepspace.DataProvider yourDataProvider; 

不过,如果你只想要一个,你可以使用一个using

using My.Namespace; 

private DataProvider dataProvider; 

这使得代码更易读。无名称类型的问题是“空”名称空间总是被“包含”。因此,考虑有My.Namespace.DataProvider和命名空间少DataProvider

using My.Namespace; 

private DataProvider dataProvider; // <-- unclear which one is used 

在上面的例子中,编译器将使用My.Namespace.DataProvider,并尽快为您删除using它会悄悄地切换到命名空间较小型。

这是违反直觉的,您通常希望将一组类型放在命名空间中以“捆绑”它们。

0

是的。

定义一个接口是为了从一个具体的实现中抽象出来(这样你就可以让其他代码模块只依赖于抽象,而不依赖于特定的实现)。

enum可以被认为是一个特定的实现(它具有特定的值),所以立即接口依赖于这个具体的实现。因此,我个人更喜欢enum被定义在与界面相同的命名空间中,以限制未来维护代码引入更多依赖的可能性(如果enum被移动到不同的项目,那么如果该项目具有依赖性,则它们变成依赖关系的界面)。

将它放在相同的名称空间中可以帮助其他开发人员将它视为接口的紧密耦合依赖关系。