2013-01-19 17 views
2

上一篇文章已刪除; 更新處理對象的通用接口w /多態性


所以我有一個獨特的問題,這可能是相當普遍的,但。屬性很可能是最常用的代碼;因爲它要求我們的數據保持恆定的價值存儲。所以我想我怎麼能實現這一點;那麼我想到泛型可以讓生活變得多麼容易。不幸的是,我們不能只使用泛型中的屬性而不需要繁重的工作。所以這是我的解決方案/問題;因爲我不確定這是最好的方法 - 這就是爲什麼我正在尋求同行的評論。

請記住,應用程序將是巨大的;這是一個非常簡單的例子。

摘要:

表示層:該界面將具有一系列的領域;甚至數據通過網絡服務傳輸到我們的數據庫。

// Interface: 
public interface IHolder<T> 
{ 
    void objDetail(List<T> obj); 
} 

所以我最初的想法是一個接口,將允許我一般處理我的每個對象。

// User Interface: 
public class UI : IHolder 
{ 
    void objDetail(List<object> obj) 
    { 
     // Create an Instance 
     List<object> l = new List<object>(); 
     // Add UI Fields: 
     l.Add(Guid.NewGuid()); 
     l.Add(txtFirst.Text); 
     l.Add(txtLast.Text); 
     // l to our obj   
     obj = l; 
     return; 
    } 
} 

現在我有一個接口;我們的用戶界面已經使用它來輸入信息。這是我好奇心的根源在哪裏被扔進混合物。

// Create an Object Class 
public class Customer : IHolder 
{ 
    // Member Variable: 
    private Guid _Id; 
    private String _First; 
    private String _Last; 

    public Guid Id 
    { 
      get { return _Id; } 
      set { _Id = value; } 
    } 
    public String First 
    { 
      get { return _First; } 
      set { _First = value; } 
    } 
    public String Last 
    { 
      get { return _Last; } 
      set { _Last = value; } 
    } 

    public virtual objDetail(List<Customer> obj) 
    { 
     // Enumerate through List; and assign to Properties. 
    } 
} 

現在這是我認爲它會很酷的地方;如果我可以使用Polymorphism來使用相同的接口;但重寫它以不同的方式執行該方法。所以接口使用了一個Generic;具有對我們給定的對象類進行變形的能力。

現在我們的對象類;可以移向我們的實體界面,該界面將處理基本的Crud操作。

我知道這個例子對我的意圖不是最好的;因爲你真的不需要使用多態性。但是,這是總體思路/目標......

  • 接口存儲表現層UI字段值
  • 實現屬性到所需的類
  • 創建一個包裝圍繞我的課;可以是Polymorphed。
  • 演變到一個通用的CRUD的操作

我在正確的道路上;這是禁忌嗎?我不應該這樣做嗎?我的應用程序需要保存每個實例;但我需要靈活性來快速適應,而不會破壞流程中的每一個實例。那是我以爲我可以解決這個問題的方式。有什麼想法嗎?建議?我在這裏錯過了一個概念嗎?還是我過度思考?我錯過了這條船,完全錯誤地實現了我的想法嗎?這就是我迷失的地方......

+2

您的客戶類看起來並不像它實現ICustomer,而且您的IEntity接口看起來比單個實體更適合集合。可能需要澄清你的問題和例子。 – 2013-01-19 01:35:02

+0

匆忙但我同意。一直在想如何在大部分時間實現這一點 – Greg

回答

0

在仔細思考了這個場景後,我想到了什麼能夠提供這種靈活性,同時仍然確保代碼針對修改和業務進行了優化。我不確定這是否是正確的解決方案,但似乎可行。它不僅工作,它很好地工作。它似乎相當強大。

此方法何時有用?那麼,當你打算將你的用戶界面與你的邏輯分離時。我會逐漸建立每個方面,以便您可以看到整個結構。

public interface IObjContainer<T> 
{ 
    void container(List<T> object); 
} 

這個特殊的結構將是重要的。因爲它會將所有需要的內容存儲在其中。

所以要開始你會創建一個窗體與一系列的字段。

  • 個人信息
  • 地址信息
  • 付款信息
  • 訂單信息

所以你可以看到所有的這些都可以單獨的數據庫表,而是屬於一個類似的實體模型你正在操縱。這很常見。

因此,關注隔離將開始稍微顯示,字段將被操縱並通過接口傳遞。

public interface IPersonalInformation 
{ 
     public string FirstName { get; set; } 
     public string LastName { get; set; } 
} 

因此,本質上接口將其變量傳遞給接口。因此,您最終將創建一個接口來處理您希望調用的整個窗體或單個接口,以便它們保持可重用。

所以現在你有一系列的接口,或者一次一次。但它包含了所有這些使用的變量。所以你現在要創建一個類:

public class CustomerProperties: IPersonalInformation, IOrderInformation 
{ 
    // Implement each Interface Property 
} 

現在你已經創建了一個容器,它將容納你所有的值。關於這個容器的好處是你可以在你的應用中爲另一個類重用相同的值或者選擇不同的值。但它會邏輯分隔用戶界面。

所以基本上這是類似於存儲庫。

現在您可以採取這些值並執行所需的邏輯。現在什麼變得美好,是在你將邏輯傳遞給我們的通用列表之後執行的。然後,只需在另一個類中實現該方法以實現目標並遍歷列表。

誠實是它似乎很好地運作,並很好地解耦。我覺得做一些類似於正常版本庫和工作單元的工作是很多工作的,這回答了這個問題,但是不管天氣如何,它對你的項目來說都是理想的,我會研究倉庫,工作單元,關注隔離,控制反轉和依賴注入。他們可能會用同樣的方法做到清潔。


更新:

我想過這個問題我寫了這件事後,我發現你實際上可以實現這些屬性值到泛型列表結構繞過了一系列的接口;但是這會引入一致性問題,因爲您必須知道每次要傳遞的數據的順序。這是可能的,但可能並不理想。