2013-12-17 130 views
12

這是實體框架:預先加載與ormlite servicestack

var department = _context.Departments 
       .Include(dep => dep.Employees.Select(emp => emp.ContactTypes)) 
       .SingleOrDefault(d => d.Id == departmentId); 

在這裏,我想到一個包含所有相關的員工和所有聯絡類型爲每個員工返回一個部門。

這是ormlite servicestack:

我不知道。當我看實況/樣本:https://github.com/ServiceStack/ServiceStack.OrmLite

他們寫道:

眼下表達支持,能夠滿足最簡單的查詢用一個強類型的API。對於任何更復雜的事情(例如使用表連接的查詢),仍然可以輕鬆地回退到原始SQL查詢,如下所示。

我看到有一個JoinSqlBuilder類,但我不認爲它可以返回嵌套集合。

也許我想是不可能的,但也許我可以這樣做讓所有員工爲DepartmentID的妥協。然後我記下每個員工,並獲取某個employeeId的所有聯繫人類型。創建層次結構和分配列表仍然是我的工作。

但我希望有一個更短的解決方案。

什麼也可能會罰款是什麼時候查詢,但它可能看起來像返回一個對象(動態?)與3個扁平屬性:部門,僱員,聯繫人類型和分配thoese屬性到我的DTO。

+1

@Voters你們應該去的所有人:http://servicestack.uservoice.com/forums/176786-feature-requests/suggestions/4459040-enhance-ormlite-with-common-data-usage-patterns並在那裏投票與您的最多3票,我們可以超過頂部的功能要求! – Pascal

+0

@Voters酷一些人已經投:對 – Pascal

+0

如果現在他們有負載參考,並保存參考檢查代碼,我從未想過使用它,因爲對第4版 – kirie

回答

0

好了,請不要把這個作爲一個明確的答案,但更多的只是我取的情況(我不使用服務棧非常多),但是...

當我第一次開始使用EF多年前,我遇到過類似的情況,其中的參考文獻不會加載。和你一樣,我面臨着不得不枚舉個人收藏自己,寫了很多額外的代碼操作的ORM應該能夠很容易地處理的可能罩。

我最終什麼事做,是使用自動映射,這基本上降低所有的多回路我不得不到處單行映射聲明。當然,我仍然必須爲每個鏈接的屬性做一個映射語句,但它減少了我必須編寫的代碼,更重要的是讓我繼續運行,直到EF得到改進,或者我找到了更好的方式做事。

讓我強調一下,我並不是建議這是一個答案,它對於評論有點大,我只是建議將思路轉向不同的方向,這可能有助於更好的解決方案浮出水面。 。