ランタイム・フレームワークって言葉は、
以前も書いたとおり、オレオレ定義なんですが、件の「
汎用モバイルバックエンド」施策のResource Serverテンプレート・リポジトリで、Resource ServerのWebAPIに属性ベースの認証メカニズムを実装しようとして思ったんですよね。「...なんか、コレ、思ったように実装できないな...。」って。
似たような話を実は「
以前」にも書いていて、今回、チョット本域で分析して、以下のように思いました。
ASP.NET MVC の Authorize属性、真面目に認証やってると、コレジャナイ感じになるな（...そもそも、Users、Rolesハードコードって...）。でも、ASP.NET Core MVC の services . AddAuthentication()、. AddAuthorization()も、コレジャナイ感あるんだよね。なんでだろうか。
AuthN も AuthZも一緒のパイプラインで良いし、ソコまでフレームワークのContext（User.Identity.IsAuthenticatedとか）に依存したコード書かんし、Coreのservices.xxxxは設定ファイルの既定のスキーマ無くして柔軟性を上げたんだろうけどI/Fとしては解り難くなってるので誰か良い感じのスキーマ設計して。みたいな事だろうか。
...今回は、 Authorize属性の話でしたが、
同様にRouting属性も解り難いですね。と言うのも、Startupクラスで実施するモノと、クラス・メソッド属性で実装するモノの２パターンがあり、且つ、ASP.NET MVC と ASP.NET Core MVC で設定方法が異なるのと、ASP.NET Core MVC の場合は、更にバージョン・アップで書き方が変わり得るからで、マニュアルを引いたりするときに混乱するからです。
コッチ（≒ 認証ではなくルーティング）は機能が単純なので、思ったように実装出来ないって話では無いですが、HTTPのメッセージ処理なんて、単なるテキスト処理なのに、なんでこんな簡単な事がサクッと出来ねーんだよｗ。みたいなイライラは常にあったりしますね。
そう言う事を考えると、ランタイム・フレームワークの使い易さの「本質」って、「
様々な共通言語・共通認識の定義」的な事なのかも知れないなぁ。なんて思ったりしました。
前回で言う、デファクト系の模倣や、空気化したデザインパターンの導入の話ですね。
そう言う事を考えると、特定分野向けに敢えて、デファクトなランタイム・フレームワークを使わない選択肢って言うのもアリなんだろうな（特に、基幹系のドでかいシステム開発の項目移送オジサン作業ばっかりヤルみたいな仕事が減って行くだろう昨今では）。...と、コレは昔から思っています。例えば、ゲーム界隈にはMagicOnionなるASP.NET代替のランタイム・フレームワークがあったりします。
なお、今回の「Resource ServerのWebAPIに属性ベースの認証メカニズムを実装する件」については、
結局、Filterのコンストラクタに、bool requireAuthentication = true, falseとかでイイかなと思った。enumにして、None, Basic, Bearerとしてもイイかも。
等と考えています。
トップページ
お知らせ
開発基盤部会
ランタイム・フレームワークについて少々、思ったことを書く。
