是用Entity.Save()，還是用DAL.Save(Entity e)

       自從上一次寫關於ORM的文章已經是幾個月前的事情了，在這裡先貼一下文章的地址，如果大家感興趣的話可以去看看。

1、支援差異資料儲存的資料庫實體類設計——處女作

2、支援差異資料儲存的資料庫實體類設計(二)(續)

3、支援差異資料儲存的資料庫實體類設計(三)(續)

4、SAS架構問世（本片部落格即將登場）

由於一直忙於架構的最佳化，所以就很少寫文章了，本文也是在不斷的最佳化自己的ORM過程中誕生的，好了廢話不多說了，下面步入正題。

 

       一直在使用公司內部使用的一個架構，架構的的資料層可以說是兩個類，一個Entity類，一個EntityFactory類，這兩個類分別是幹嗎就不多講了。在不斷編碼的過程中總是發現在重複的寫EntityFactory.Save(e)、EntityFactory.Delete(e)這樣的代碼，心裡就在想可否做一下處理，直接調用Entity.Save()，或者Entity.Delete()這樣寫起來方便，看起來也很順眼。

       直到最近在最佳化自己的架構代碼的時候，才發現Entity.Save()是不太合適的，特別是當你的應用程式需要串連到多個不同的資料庫的時候，而且你也不知道當前這個Entity對應於哪個資料庫，或者說同一個Entity對應於多個資料庫的時候，使用Entity.Save()操作估計就很難辦了。

       假設：MSSqlDAL是Sql Server資料庫的資料層，在儲存實體物件的時候，你可以通過下面方法完成(Entity e)

1. MSSqlDAL.Save(e);
2. 或者你在Entity中增加一個方法public void Save(){ MSSqlDAL.Save(this);}，然後調用e.Save()。

       兩種方法視乎都可以達到效果，但是現在如果我們的系統需要在另外一個資料庫存一個副本，即同一個對象會存到兩個不同的資料庫（可能是SqlServer，也可能是Oracle），這個時候，我們需要增加一個Oracle資料庫的資料層OracleDAL.所以如果這個時候來調用e.Save()方法就出現問題了。

 

最後總結一下，最終定下來採用Dal.Save(e)儲存對象是正確的，因為強制性給實體物件增加一個Save()方法，似乎有點說不通，因為對象本身並沒有儲存這個動作。而是由資料層來負責儲存資料庫實體物件，這也符合OO原則。

 

ASP.NET開發技術交流群： 67511751