EasySqlParserを作った動機 その１
なぜ作ったのか？
- SQLを生で書きたいときもある
- どのORMを使うにせよSQL文をソースコード中に埋め込みたくない
- Java経験(s2dao,s2jdbc)が長かったためか 2-way-sql が欲しくなってしまった
- 開発者全員がラムダ式を使えるわけではない
- 分かりやすいログを見たい
- OSSへの貢献
1. SQLを生で書きたいときもある
これはEntityFrameworkに限った話です
簡単なクエリであればEntityFrameworkでタイプセーフに書けます
しかしながら、正規化した結果テーブル結合が10個とかになる場合もあります
それ以外にもSQLだけで解決したほうが楽な場合も少なくないです
ただ単におまえがSQL書きたいおじさんだろと言われれば反論できないですがw
2. どのORMを使うにせよSQL文をソースコード中に埋め込みたくない
.NET界隈ではおそらくDapperとEntityFramework(Core含む)のツートップかなと思いますが、そう言ったO/R Mapperに対してSQL文をソースコード中に埋め込むことはしたくないのは自然な欲求かと思います
これは後述の「3」があるため余計にそう思っているのかも(´・ω・`)
3. Java経験(s2dao,s2jdbc)が長かったためか 2-way-sql が欲しくなってしまった
2-way-sqlという発想は、私の知る限りでは下記のとおりです
最初の実装はおそらくs2dao(15年以上前)だと思います
s2daoは既にEOLなので多くは書きません
昔話を知りたい方は適当にググってくださいw
今でもオフィシャルページが生きています
単独で使えるわけではなく、s2containerなど周辺ライブラリとともに使います
これはJavaEEへのアンチテーゼとして書かれているためで、いろいろひっくるめていわゆるフルスタックなフレームワークです
たぶん
s2jdbcはs2daoの後継です
これもEOLなので(ry)
そんなわけでJava界隈ではこれ以外にもいろいろプロダクトがあります
ほかにもあるようですが現時点で使えそうなものはこれくらいかと
機能的はDOMA一択かと思います
また、.NET向け 2-way-sql パーサで検索すると以下のものが出てきます
どれも使いたいものではありませんでした
更新されていないので論外
- DBFlute.Net
更新さ(ry)
- Dapper.outsidesql
EasySqlParserのコードができてしまってからこの存在を知ったのでどうしようもなかったw
2-way-sqlというのは一度経験してしまうと、そこから脱却できないくらいの悪魔的なライブラリです
筋金入りの.NETエンジニアにもぜひその魔力に取りつかれてほしい
EasySqlParserで！！
要は2-way-sql依存おじさんになっていたということですw
なんか長くなったので半分まで行ったので次回に持ち越します
