Oracle LINQ之路
自從學會LINQ to SQL後，我就愛死那種忘記SqlConnection、丟掉SqlCommand、抛下SqlParameter的簡潔，乾乾淨淨幾行Code就搞定查詢、新增、修改、刪除的感覺。
無奈在公司，就算先撇開專案團隊成員是否已具備LINQ技能的問題，面對Oracle林立的工作專案環境，抬出LINQ to SQL無疑是張飛打岳飛，只能乖乖回去用OracleCommand、OracleParameter行禮如儀。
不過，我還是沒有放棄在Oracle專案使用LINQ的念頭。ADO.NET Entity Framework(以下簡稱EF)被視為微軟在資料庫存取層的明日之星，在架構上可以跨料庫，只要找到對的Provider，原則上程式不用修改就可以抽換資料庫。
由目前的走向來看，LINQ to SQL將會漸漸淡出。但對於一些時桯緊迫的專案來說，我始終覺得用LINQ to SQL更加簡便直覺，才是快速開發的王道。(有點遺憾在這個議題上，微軟的想法並不像WebForm vs MVC，採二者並行而不互相排擠，幾乎確定未來會由EF一統江山，LINQ to SQL將不會再持續發展)
"快速建置系統，滿足User急如星火的需求"是我工作上大部分專案的特性，因此在系統開發上不太容易爭取空間好反覆琢磨、精心打造出以嚴謹架構取勝的系統。換句話說，工具愈輕巧，愈能在較侷限的空間中有所發揮。在只有40坪大小的地基，就不要妄想打造台北101，凡事都要因地制宜；在必須低著頭走路的坑道，倚天劍還不如一把瑞士刀，如此才是生存之道。(謎之聲: 這樣也要押韻，你夠了沒?)
回到要在Oracle上使用LINQ的議題上，EF未內建Provider for Oracle，而微軟跟Oracle不知是否基於業務策略考量，都遲遲沒有任何補足這塊的計劃，所以現階段要實現結合LINQ與Oracle的理想，需仰賴3rd Party廠商的解決方案。在網路上爬找了一陣子，挖到一些解決方案: (包含我不負責任的簡短評論)
- Open Source專案: Linq to Oracle
免費且有原始碼，但看來並未被廣泛應用，改版次數有限，而上次版本更新是近一年前的事。真要使用得負擔自行Debug及修改的責任。少了廠商背書，應用在工作專案裡，除了搞Business Logic外，還要留意問題是否為DAL層Bug引起，個人認為較不妥當。
- Open Source專案: DB_Linq
最後一個版本是2008/09，存在的疑慮跟Linq to Oracle差不多，而且它的目標訂成跨平台，Oracle、PostgreSQL, MySQL, Ingres, SQLite通吃，但相對的，對Oracle的專精度只怕會更低。
- Sample ENtity Framework Provider for Oracle
一樣是一年多前發表的，而且文章上已經表明了"This is an unsupported sample and should be treated as such. Although reasonable effort has been put to make sure that basic EF scenarios work with Oracle, there are certain limitations. Use in production environment is strongly discouraged."，那... 玩玩就好，別把自己的事業押在上面!
- DataDirect的ADO.NET Oracle、devart的dotConnect for Oracle
這兩個總算是廠商持續支援的解決方案了，是目前市場上公認兩大EF Oracle Provider商業產品。二者在產品特性上不相上下，都支援免裝Oracle Client直接連線、LINQ to Entity、Entity SQL。至於採購成本，有趣的是DataDirect在網站並未列出明確授權價格，只留下一支電話；而dotConnector則是單一授權$299.95，四個開發者優待價$699.95，企業吃到飽方案$1799.95。
看來，現階段若真想在Oracle玩LINQ，應該就是在DataDirect與devart兩個產品擇一。Survey過程中，最讓我驚喜的一件事，莫過於dotConnect for Oracle支援所謂的LINQ to Oracle。也就是說，devart比照LINQ to SQL實作出了對應於ORACLE的版本，讓深愛輕巧工具的我十分動心。
皮卡丘LINQ to Oracle，就決定是你了!
後續，我打算花點時間試用一下，先應用在一些小專案上，有心得再跟大家報告。