太多抽象/接口

我正在設計我的數據訪問代碼的過程中，數據將被存儲在RavenDB中，並且我正在嘗試查看我的當前設計是否具有太多抽象與接口的數量I我會去的。太多抽象/接口

我將擁有將持有數據的DTO，然後我將擁有將具有額外功能的實體（或模型，商業或任何您稱之爲它們的對象）。我還將爲每個實體定義需要具備的數據。因此，例如：

interface IUser 
{ 
    string Id { get; } 
    string Username { get; } 
    string Password { get; } 
    bool ResetPassword { get; } 
} 

class UserDTO : IUser 
{ 
    public string Id { get; set; } 
    public string Username { get; set; } 
    public string Password { get; set; } 

    public UserDTO() 
    { 
     Id = null; 
     Username = null; 
     Password = null; 
     ResetPassword = false; 
    } 
} 

class User : IUser 
{ 
    public string Id { get; set; } 
    public string Username { get; set; } 
    public string Password { get; set; } 

    public User() 
    { 
     Id = null; 
     Username = null; 
     Password = null; 
     ResetPassword = false; 
    } 

    public User(IUser user) 
    { 
     Id = user.Id; 
     Username = user.Username; 
     Password = user.Password; 
     ResetPassword = user.ResetPassword; 
    } 

    public ResetPassword() 
    { 
     Id = null; 
     Username = null; 
     Password = null; 
    } 
}

我想爲每個實體的接口的原因是因爲我要確保兩者EntityDTO和Entity具有所需的共享數據。

現在爲了檢索和保存數據，我將使用存儲庫模式。我將有一個名爲IDataRepository的通用接口，然後每個實體都將擁有自己的存儲庫接口。例如：

interface IDataRepository<T> 
{ 
    bool Save(T entity); 
    bool Delete(T entity); 
} 

interface IUserRepository : IDataRepository<IUser> 
{ 
    IUser Load(string key); 
    IUser LoadByLogin(string username, string password); 
} 

class UserRepository : IUserRepository 
{ 
    bool Save(T entity) 
    { 
     //save code 
    } 

    bool Delete(T entity) 
    { 
     //delete code 
    } 

    IUser Load(string key) 
    { 
     //load code 
    } 

    IUser LoadByLogin(string username, string password) 
    { 
     //load code 
    } 
}

我想爲每個實體存儲庫接口的原因是，我可以的，如果我需要使用不同的實體不同的數據存儲選項。

這是否看起來太抽象了？

來源

2011-03-30 ryanzec

爲什麼區分'User'和'UserDTO'？ – ChaosPandion 2011-03-30 21:54:11

這看起來像抽象嗎？你什麼意思？你能澄清你想達到什麼嗎？ – roosteronacid 2011-03-30 21:57:39

因此，您從存儲庫加載IUser。接下來你會做什麼？將其轉換爲用戶？另外從所提供的信息來看，沒有證據表明DTO是真正必要的。 – driushkin 2011-03-30 22:30:06

我覺得這個模型有它的貨物和壞處。如果你的DTO要與實體相匹配，爲什麼要有DTO？在某些系統中，這是需要發生的事情，而在另一些系統中則是浪費時間。根據ORM，實體通常具有行李並且不會很好地序列化。如果使用該接口，則可以使用AutoMapper完成DTO和實體之間的映射，並且每次都應該運行良好。你需要讓Entity類在DTO的獨立DLL中生存嗎？如果是這樣，我認爲你的模型起作用

來源

2011-03-30 21:58:28 CrazyDart

你從本質上看對我來說很好。

但是，除非你有進一步區分DTO和實體類，並明確需要將兩者分開，否則我只需簡單地將User擴展爲UserDTO並將所有接口一起移除。這樣，您可以刪除當前擁有的代碼冗餘。

來源

2011-03-30 21:58:31

是的，這太抽象了。具體來說，我不認爲需要類對象。

IUser本身應該定義數據存儲庫完成其工作所需的完整接口。如果存儲庫被交給一個實現了IUser的對象，例如User，那麼它應該能夠很好地存儲數據。而且，由於接口是在最低級別定義的，因此省略UserDTO對象不會產生任何依賴性問題。

來源

2011-03-30 21:59:07

我不認爲我們對系統有足夠的瞭解來說明它太多。如果這是一個正在公司內部分發給項目的DLL，那麼你是否仍然希望傳回可能掛鉤的實體而不想提供訪問權限？ – CrazyDart 2011-03-30 22:08:10

@CrazyDart - 如果OP擔心實現存儲庫層的人將要在其IUser實例上使用反射來獲得受限功能的訪問權限，那麼這個問題應該在問題中明確說明！ – 2011-03-30 22:17:10

太多抽象/接口

回答

相關問題