在Umbraco中使用實體框架或任何其他ORM

我想找到一些文檔/文章，其中有人已經在umbraco中整合了實體框架（或任何其他ORM工具），而不是使用基於良好的舊文本的SQL查詢。在Umbraco中使用實體框架或任何其他ORM

截至目前，如果我想查詢數據庫一把umbraco我寫的東西如下：

ISqlHelper SqlHelper = DataLayerHelper.CreateSqlHelper(umbraco.GlobalSettings.DbDSN) 

    SqlHelper.ExecuteNonQuery(@"insert into Table(id,ColumnName)      values(@id,@ColumnName)", 
    SqlHelper.CreateParameter("@Id", -1),     SqlHelper.CreateParameter("@ColumnName", foobar),

這很好（不要誤會我的意思），但我認爲它可能是用某種更好ORM工具。

有關如何使用ORM工具來連接現有Umbraco表以及新表的任何想法/想法？

來源

2012-12-05 daehaai

我在我的umbraco應用程序中廣泛使用EF，它工作得非常好，但不能操縱核心umbraco表;我用它來操縱我添加到數據庫的自定義表格。

我甚至不確定umbraco表是否會默認設置所有正確的外鍵和/或索引來優化EF的使用並使其值得。

如果您只是想讓包容器更易於訪問核心表，請考慮使用輕量級包（如Dapper）。

來源

2012-12-05 11:36:15

很好的一點在第二段。 – daehaai

我在很多Umbraco項目中使用過Linq to SQL，但在去年已轉向使用PetaPoco。 PetaPoco是非常輕量級，簡單易學，實施和使用。它也非常快。

我發現EF和Linq to SQL沒有特別的顛覆性，當兩個或更多的開發人員工作在相同的數據模式時會導致衝突。

我還發現，使用DI實現PetaPoco更直接，因爲沒有上下文需要考慮。對我來說，這感覺像與Umbraco 4.10+項目的MVC實現天然契合。

更新：

已經轉移到一把umbraco V6 +（其本身使用PetaPoco），我經常發現我甚至都不需要安裝一個ORM，因爲我可以用一把umbraco自己的數據庫對象，因爲就像我說的實際上是PetaPoco。但是，當我需要更多的「咕嚕聲」時，我會選擇NHibernate或EF，但這些情況很少，而且如果可能的話，我會很樂意繼續使用Petapoco或NPoco。

來源

2012-12-05 12:43:37 Digbyswift

如果您使用edmx，'可能'的源控制部分只是一個問題。我正在談論POCO對象，它可以與任何源代碼控制系統配合使用。當然，問題的一部分是，它不是簡單的在svn有像TFS這樣的專屬結賬:) – daehaai

這是我的兩分錢。 :)

EF或任何ORM映射器，你可以採取和選擇工作，以滿足您在umbraco生態系統的需求。好處是你可以採用你自己的查詢編寫模式來查詢Umbraco DB。它會完美地工作。

一旦您採用EF，您將有如下疑問。

var q = from p in cmsContentType.Include("umbracoNode")

同樣..你也可以有一些類包裝保存存在於EDMX一把umbraco表的實體。

但是，如果您的意圖是在同一個數據庫中有一些自定義表以及Umbraco表，那麼我建議您創建兩個EDMX文件-1對於Umbraco表和2 Nd對於自定義表。這樣您可以減輕一個EDMX文件的負擔，並獲得性能。

回答你的問題......雖然沒有可用的文檔可以做到這一點..你可以認爲你有大量的表，並把它們放在EDMX上，並開始使用它。

下面附加的是我的數據庫中的圖像，這是香草風味umbraco。

enter image description here

來源

2012-12-06 07:53:19

我不是edmx tbh的粉絲。我更喜歡POCO，這給了我更大的靈活性。無論哪種方式，你不會有像下面描述的@ e-j-brennan相同的問題？ – daehaai

我是ej-brennan @ SO的邊緣粉絲，但我認爲Umbraco的數據庫模式很好定義..如果你想看看你的自我安裝一個新的，並從SQL服務器看數據庫圖，他們有很好的FK-PK關係。根據我。所以你也不會遇到EDMS問題。 –

用EF-ERD視圖更新我的答案。 –

在Umbraco中使用實體框架或任何其他ORM

回答

相關問題