Entity Framework筆記:使用Oracle Synonym

遇到EF使用Oracle Synonym問題,查了資料做了實驗,整理筆記如後。

先說我們在Oracle使用Synonym(別名,有人翻成「同義詞」,我覺得別名順口)的情境:例如人事系統使用"HR"帳號登入Oracle並在自己的HR Schema建立資料表並擁有HR Schema所有資料表的讀寫權限。之後ERP系統要讀存HR Schema下的員工基本資料,當然不能直接用HR帳號密碼連Oracle,而會另開HRQRY之類的帳號,再授與其HR.Employee資料表的讀取權限。這種場景在SQL Server也很常見,只需連線字串改用HRQRY帳號登入,Initial Catalog改指向HR資料庫,用SELECT * FROM Employee就能查到資料。Oracle的Schema概念有點不同,沒法在連線字串用Initial Catalog指定Schema,HRQRY要存取HR下的資料表,得寫成SELECT * FROM HR.Employee。這樣做有兩個缺點,一是每次動用Table時都要加上"HR."挺囉嗦,二是在程式碼寫死了Schema名稱,一旦Schema名稱調整將有改不完的程式。簡便的解決之道是為HR.Employee建立Synonym:
CREATE PUBLIC SYNONYM Employee FOR HR.Employee;

如此,以HRQRY登入也能用SELECT * FROM Employee查詢HR.Employee,如要改由其他Schema讀取Employee,只需重設Synonym,不必改程式。

不過這個做法搬到Entity Framework會遇到一點小挑戰!在Visual Studio建立EF模型時,Entity Data Model Wizard/Choose Your Database Objects(操作畫面請參考舊文) 看不到任何Synonym資料表,換句話說,我們無法使用HRQRY帳號為Synonym資料表建立資料模型!

爬文找到CodePlex EF專案的一則討論,開發團隊基於應用需求不多的理由,未將Synonym納入Entity Data Model Wizard的找尋範圍,這就是操作介面看不到Synonym資料表、檢視、Stored Procedure的原因。

要解決問題,有兩個選擇:

  1. 開發階段以原帳號(HR)連線資料建立資料模型,測試及上線時再改用HRQRY。
  2. 如果能接受Code First開發模式(延伸閱讀),OnModelCreating()事件允許指定Schema名稱,如此連Synonym都不需建立。

我們目前開發上已習慣EDMX的視覺化呈現,暫時沒有轉往Code First的打算,故選擇第一種做法。而依據實測,先用HR建好模型,只要Synonym名稱齊全,與原資料表名稱一致且權限有開,連線字串的登入帳號由HR換成HRQRY即可無縫接軌,不需更動任何程式碼,還算方便。

爬文期間還查到一篇Synonym名稱與原資料表不同,如何修改EDMX配合的Hacking技巧,一併記下備忘。

歡迎推文分享:
Published 31 July 2016 09:09 AM 由 Jeffrey
Filed under: ,
Views: 3,494



意見

沒有意見

你的看法呢?

(必要的) 
(必要的) 
(選擇性的)
(必要的) 
(提醒: 因快取機制,您的留言幾分鐘後才會顯示在網站,請耐心稍候)

5 + 3 =

搜尋

Go

<July 2016>
SunMonTueWedThuFriSat
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456
 
RSS
創用 CC 授權條款
【廣告】
twMVC

Tags 分類檢視
關於作者

一個醉心技術又酷愛分享的Coding魔人,十年的IT職場生涯,寫過系統、管過專案, 也帶過團隊,最後還是無怨無悔地選擇了技術鑽研這條路,近年來則以做一個"有為的中年人"自許。

文章典藏
其他功能

這個部落格


Syndication