2013-04-03 62 views
0

我在數據訪問層的一類,說BaseDAL具有標準的插入,更新,刪除的方法。 從我的業務邏輯層爲我的應用程序中的所有實體使用相同的類,或者爲所有實體創建多個DAL類並將它們用於數據訪問是否好? 換句話說,有什麼更好的? 爲多個客戶端提供服務的同一個類的多個實例或爲其各自實體提供服務的獨立類的單獨實例?C#多個對象VS多類

+1

如果有其中一些客戶端不需要看到它是更好地使用其他類領域。在這種情況下你可以使用接口。 – Dilshod

+0

你能舉個例子嗎?這不是100%清楚你問什麼,我認爲一個例子會讓你真正的問題清楚。例如,也許你有一個動物數據庫,你有一些只處理貓的客戶。這是你的問題嗎?你也可能意味着你有相同的動物分貝,你有一個客戶只處理一個名爲喬治的動物。 – Hogan

回答

1

取決於你需要多久做改變實體,你是多麼的靈活性需要,你需要多快辦編寫代碼。

最佳實踐說,你必須爲每個層(DAL,BL,表示層)創建單獨的實體類。這將導致最靈活的架構。

但是這樣的解決方案的缺點是,你需要編寫大量的轉換器方法,性能往往會下降一點,而最重要的是 - 如果你做垂直變化(影響所有圖層) - 你必須改變很多代碼。因此,如果你的應用程序是單次使用的,而且你知道它的壽命不會超過幾個星期/月,那麼可以證明不會有太多的靈活性來支持更快地創建應用程序。但我再次強調 - 只適用於短生活小應用程序。

我經常使用具有用於所有層的這樣的實體類所有公共屬性共同基座接口(I通常有3實體類:用於DAL,BL,PL分別)和寫單個轉換器類他們。它在需要時仍具有足夠的靈活性,但允許編寫更少的代碼。

對不起,我誤解了起初的問題。這裏是更新

至於數據訪問存儲庫類,它當然更好地將功能拆分成部分(可能基於實體類型)。否則,你很快就會得到成千上萬的文件。

而且還出現了一個設計原則「單一職責原則」。根據它,分割功能也更好。儘管可以認爲所有的數據訪問方法在頂層都有單一的責任,但他們採取了非常不同的行動,並與不同的實體一起工作。

+0

我在有關圖層的問題中看不到任何東西。這與此有何關係? – Hogan

+0

對不起,我誤解了這個問題。現在編輯。 –

0

事情是這樣的:

public interface IPerson 
{ 
    string Name{get;set;} 
    string LastName{get;set;} 
    //do not add fields which client doesn't need 
} 

public class PersonServerSide : IPerson 
{ 
    //implement IPerson 
    public string SSN{get;set;} //client doesn't need this for example 
} 

public class PersonClientSide : IPerson 
{ 
    //implement IPerson 
} 
+0

這個答案似乎與這個問題無關,你能解釋一下它的關係嗎? – Hogan

+0

@Hogan這只是他如何實施他的項目的一個例子。 – Dilshod