2019-05-15

EasySqlParserを作った動機その２

前回の続き

4. 開発者全員がラムダ式を使えるわけではない

これもEntityFrameworkに限った話です¹

var query = DbContext.Employees.Single(e => e.EmployeeId == 1);

このような記述を見てSQLしか知らないおじさんがいきなり理解できるのか？
と言われると厳しいものがある

知らんけど

~~個人的な見解では.NET 3.5でLINQが登場してから10年以上たっているのにラムダ式使えないとかありえなくね？という気はします~~

現実は非常である(ポルナレフ風に)

よろしい、ならば素直にSQL文を書こう
からのEasySqlParserです

交換可能な技術があって、生産性などの面から見ても問題なければ
できるものでやればよい
それが自由というものだ()

5. 分かりやすいログを見たい

これもEntityFrameworkに限(ry)

SELECT TOP(@__p_0) [e].[BusinessEntityID], [e].[ModifiedDate], [e].[rowguid], [e.Person].[BusinessEntityID], [e.Person].[AdditionalContactInfo], [e.Person].[Demographics], [e.Person].[EmailPromotion], [e.Person].[FirstName], [e.Person].[LastName], [e.Person].[MiddleName], [e.Person].[ModifiedDate], [e.Person].[NameStyle], [e.Person].[PersonType], [e.Person].[rowguid], [e.Person].[Suffix], [e.Person].[Title], [e.Person.Employee].[BusinessEntityID], [e.Person.Employee].[BirthDate], [e.Person.Employee].[CurrentFlag], [e.Person.Employee].[Gender], [e.Person.Employee].[HireDate], [e.Person.Employee].[JobTitle], [e.Person.Employee].[LoginID], [e.Person.Employee].[MaritalStatus], [e.Person.Employee].[ModifiedDate], [e.Person.Employee].[NationalIDNumber], [e.Person.Employee].[OrganizationLevel], [e.Person.Employee].[rowguid], [e.Person.Employee].[SalariedFlag], [e.Person.Employee].[SickLeaveHours], [e.Person.Employee].[VacationHours]
FROM [Person].[BusinessEntity] AS [e]
LEFT JOIN [Person].[Person] AS [e.Person] ON [e].[BusinessEntityID] = [e.Person].[BusinessEntityID]
LEFT JOIN [HumanResources].[Employee] AS [e.Person.Employee] ON [e.Person].[BusinessEntityID] = [e.Person.Employee].[BusinessEntityID]
WHERE [e.Person].[MiddleName] = N'J'

これはEasySqlParserのサンプルアプリと同じようなデータを取得した場合に出力される、EntityFrameworkのログです

いや、かなり厳しいw
特に 2-way-sql が出力するログに見慣れているとw

不要なカラムは見たくないし、項目ごとに改行して欲しいのが人情というもの

まぁA5:SQL Mk-2に張り付けて整形すれが言い訳ですが

SELECT
    t0.BusinessEntityID
  , t1.FirstName
  , t1.MiddleName
  , t1.LastName
  , t0.BirthDate
  , t0.MaritalStatus
  , t0.Gender
  , t0.HireDate
FROM HumanResources.Employee t0
INNER JOIN Person.Person t1
  ON t0.BusinessEntityID = t1.BusinessEntityID
WHERE



   t0.BirthDate BETWEEN '1980/01/01 0:00:00' AND '1990/01/01 0:00:00'



ORDER BY
  t0.BusinessEntityID

これはドキュメントにも書いているEasySqlParserが出すログです
SQLファイルに書いてある通りに改行され、書いた通りの項目が出力されます

どちらが見やすいかは一目瞭然かと思います

6. OSSへの貢献

エンジニアの端くれである以上、OSSというエコシステムに少しでも貢献したいという思いがあります

また、日ごろからOSSを利用しているのに何の恩返しもできないのはどこか後ろめたいものが少なからずありました

かといって他のOSSにPRを送るほど私にはスキルがありません

ということでOSSを作って貢献しよう(ありそうでない＋自分が欲しい .NET向け 2-way-sql パーサーを書いてしまおう)
と思い立ったわけです

Dapperでも結果セット取ってきて後からクエリ書く場合もあるかな？
最近まともに触ってないのでよくわかりませんw↩

2019-05-14

EasySqlParserを作った動機その１

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という発想は、私の知る限りでは下記のとおりです

Java由来
ガラパゴステクノロジー(日本産)

最初の実装はおそらくs2dao(15年以上前)だと思います
s2daoは既にEOLなので多くは書きません

昔話を知りたい方は適当にググってくださいw
今でもオフィシャルページが生きています

単独で使えるわけではなく、s2containerなど周辺ライブラリとともに使います
これはJavaEEへのアンチテーゼとして書かれているためで、いろいろひっくるめていわゆるフルスタックなフレームワークです

たぶん

s2jdbcはs2daoの後継です
これもEOLなので(ry)

そんなわけでJava界隈ではこれ以外にもいろいろプロダクトがあります

ほかにもあるようですが現時点で使えそうなものはこれくらいかと

機能的はDOMA一択かと思います

また、.NET向け 2-way-sql パーサで検索すると以下のものが出てきます

どれも使いたいものではありませんでした

S2Dao.Net

更新されていないので論外

DBFlute.Net

更新さ(ry)

Dapper.outsidesql

EasySqlParserのコードができてしまってからこの存在を知ったのでどうしようもなかったw

2-way-sqlというのは一度経験してしまうと、そこから脱却できないくらいの悪魔的なライブラリです
筋金入りの.NETエンジニアにもぜひその魔力に取りつかれてほしい
EasySqlParserで！！

要は2-way-sql依存おじさんになっていたということですw

なんか長くなったので半分まで行ったので次回に持ち越します

2019-05-13

.NET 向け 2-way-sql パーサを作ってみた

EasySqlParser

DOMAや uroboroSQL で使うようなSQLファイル(いわゆる 2-way-sql として書かれたSQL)をパースするライブラリを作りました。

DapperやEntity Framework(Core含む)もあるのに今更？？
と自分でも半分くらいは思いながら諸事情により作ることになりました

諸事情の話やドキュメントに書ききれない部分などは長くなるので後で書きます

たぶんw

2017-09-22

EntityFramework Core 2.0のScaffoldで生成されるコードをカスタマイズする

EntityFramework Core ASP.NET Core

長らく業務アプリ開発で洗脳鍛えられた開発者は未だにコードファーストに馴染めない
と思うのは気のせいでしょーか？？(´・ω・`)

というわけで、DBファースト(DB設計してから)コードを書く場合、
一から書いてもいいが大して利用頻度が高くないようなマスタメンテなんかはやってられないので
Ruby On Railsでも有名なScaffoldがASP.NET Coreでもできるので楽をしようという話(が本題ではないw)

パッケージマネージャーコンソールの場合はScaffold-DbContext
コマンドラインだとdotnet ef dbcontext scaffold
でDBからMVCのMができる

次にコマンドラインでdotnet aspnet-codegeneratorを叩くと
MVCのV、Cができあがる
※こちらはパッケージマネージャーコンソール版は無い(理由は知らない)

VIEWは一律で

Create
Delete
Details
Edit
Index

ができあがる
内容は名前から想像できるので省略

生成されたVIEWの中のコードは当然？日本語など一切なく

<label asp-for="MailAddress" class="control-label"></label>
<input asp-for="MailAddress" class="form-control" />

こんなコードが生成される
Index以外のVIEWは上のようなlabel＋inputが基本の模様

このまま実行してブラウザに表示させてもラベルは英語の「MailAddress」にしかならない
自分だけが操作するなら英語のままでもいいかもしれないが
他人が使うのであればやはり日本語で「メールアドレス」と出てほしいと思うのが人情というもの

そこで生成したModelのプロパティに旧来のASP.NET MVCでもやっていたDisplay属性をつけることで日本語を出力できる

今回の例だと[Display(Name = "メールアドレス")]

しかしこれを手で追加するのは煩わしいことこの上ない

怠惰な開発者であれば自動化したいところ

そこでICSharpEntityTypeGeneratorなどを実装することで自動化ができる

と言っても実際はCSharpEntityTypeGeneratorという実装クラスがあるのでそこからコピペしていじくるだけの簡単なお仕事

githubにSqlServer用のサンプルを上げたので参考になればと…

上記サンプルの CommentHelper 内の ConnectionString を編集してScaffoldすればDisplay属性付きのModelが生成されるはず

※複数プロジェクトがある場合はスタートアッププロジェクトにしておかないとMyDesignTimeServicesが呼ばれないという落とし穴があるのでご注意を

2017-09-13

AnkhSVN on Visual Studio 2017

Visual Studio 2017

git使わ(え)ねぇエンジニアはエンジニアじゃねぇ！的な時代になって早数年

しかし日本の中にはsvn(SubVersion)という旧石器時代の環境を使っているところも多いはず(根拠なし

ほとんどの人はVisual Studioからsvnのソースを上げたりするのにはAnkhSVNというツールを使っていると思いますが

VS2017でAnkhSVNを使って初期コミットをする際にVSがcrashしてはまったのでメモ

Commit files in the initial commit のチェックボックスを外すだけ

(デフォルトはON)

f:id:on-take-3:20170913032207j:plain

半年も前にオフィシャルのディスカッショントピックに上がっていたのにようやくたどり着いた。。。

2016-07-31

はじめてのGit

github Visual Studio

はじめてgitを使った。
いや、正確にはgithubを。

git cloneは何回もしたことありますが(monoとかmonoとか、あとmonoとか)
Visual Studio Extension用に書いたソースなんぞを上げてみました。

AddRegionVSPackage
名前から想像できるようにソースコードにregionをつける簡単なお仕事です。

しかし仕事ではJava(intra-mart)の呪縛から逃れられず
長いこと.NETのコードを書いてません。
いや、オレオレツールは作ってますが、結構やっつけで書いたりするので使う機会がそんなにない…

そこで問題だ。
このプラグインを積極的に使うにはどうすればいいのか。

3択―ひとつだけ選びなさい

答え①on-take-3は突如反撃のアイデアがひらめく
→反撃できる状況ならとっくに反撃してるよね

答え②仲間がきて助けてくれる
→ヘッドハンティングとかですか？はい喜んで！(爆

答え③かわせない。現実は非情である。
→このまま死ぬまでintra-martとかなんという罰ゲーム

ということで答えは②かな(違う

2016-07-05

ポモドーロテクニック

恐ろしい。

decode2016から早くも１か月以上も経ってしまった…

そして前回のブログ投稿からは4年も…

Windowsは8から10になった…

decodeでまつもとゆきひろさんが紹介していたSOFT SKILLSを読んでいます。 (まつもとさんのセッションには参加したかったけど他に聞きたいのがあったので聞けなかった)

ポモドーロテクニックはその中で紹介されていたもので

25分集中して5分休むというのを繰り返して行うことで生産性を高めるテクニック大事なところをは集中することではなくて

ポモドーロを1日に何回行ったか
仕事をこなすのに何ポモドーロ使ったのか

を数えるところにあり、やがて

どれくらい一生懸命働いたか
自分は何ポモドーロ使用できるのか

がわかるようになってタスクの割り振りも的確になって生産性があがるようだ。

~~まぁ、でもこれってコピペマンのようなプログラマーには無縁な話ですよね(爆)~~