Daoの利用基準について

[nishi.74322014]

Q&A履歴を纏めました。

（１）次のような使い分けで認識合っていますでしょうか？

　　また、① は、ツールで自動生成なので手作成作業は無く、

　　② は、逆に全て手作成の認識ですが、こちらも合っていますでしょうか？

　　①自動生成D層

　　　⇒　基本4メソッド（テーブルの全カラムor指定のカラムに対するSELECT/INSERT/UPDATE/DELETE)

　　②動的パラメタイズド・クエリ

　　　⇒　基本4メソッド以外（JOINしたりUNIONしたり副問合せしたり・・・）

　　→ 合っています。

（２）手組のSQLファイルを自動生成D層と同じ方式でB層でD層に紐づけてDBアクセスさせる方式

　　手作成SQLのDBアクセス方式として、パラメタライズドクエリを使わずに、手組のSQLファイル

　　（静的なSQL構文を自動生成されたものを流用するなどして作成したテキストファイル）

　　を自動生成D層と同じ方式でB層でD層に紐づけてDBアクセスさせる方式にしようとしています。

　　（先行開発で、実現できることは確認しました。SQLのコード量は増える可能性がありますが、

　　開発や保守の学習コストが小さそうではと考えたり、性能対策が必要になった時にしやすいのではと考えています。）

　　何か致命的な問題等ございましたら、ご指摘を頂けますと助かります。

　　→　データアクセスには様々なパターンがあるので、個別に、工夫してもらってOKと思います。

　　　　D層（Dao）の種類 - Open 棟梁 Wiki

　　　　https://opentouryo.osscons.jp/index.php?D%E5%B1%A4%EF%BC%88Dao%EF%BC%89%E3%81%AE%E7%A8%AE%E9%A1%9E

　　　　・自作Daoクラス

　　　　・汎用Daoクラス（CmnDao）

　　　　・自動生成Daoクラス

（３）複数テーブルを結合するSQLの生成機能

　　複数テーブルを結合するSQLの自動生成を

　　Open棟梁でできないか？と考えています。

　　テーブル結合SQLの自動生成ツールより

　　・SQLの記述の統一化（保守性の向上）

　　・SQLのコーディングミス（SQLインジェクションなどのセキュリアコーディング含む）の排除

　　が見込めるので、製造工程の効率化に加えて、テスト工程でも効率化ができる、ととらえています。

　　（a）テーブル結合SQLの自動生成ツールを作ったことはありますか？

　　　　SQL定義ファイルの生成なので、所定の詳細設計書のフォーマットからの生成などを考えています。

　　（b）Open棟梁が自動生成するsqlを利用する前提とし、（a）は利用しないような

　　　　Open棟梁のコーディングルールや手順がありましたら、教えてください。

　　メインテーブルの select → マスタテーブルのレコード検索

　　（マスタ×メインレコード数分の繰り返し）とすると

　　SQL発行回数が多くなるので、性能に影響がありそうなものと考えました。

　　→　以下、回答になります。

　　　　（a）テーブル結合SQLの自動生成ツール開発の事例はなく、

　　　　　・基本的には、以下の様に考えています。

　　　　　　・単テーブルSELECT以外のSQLは基本的にCmnDao経由で実行。

　　　　　　・JIONクエリ作成は、クエリ・ビルダなどのツールを使用

　　　　　　　https://docs.microsoft.com/ja-jp/sql/reporting-services/report-data/graphical-query-designer-user-interface?view=sql-server-2017

　　　　　　　SQL ServerのExpressでも使用できそうです。

　　　　　　・上記で生成したクエリを「動的パラメタライズド・クエリ分析ツール」を使用してタグ付け＆動的化。

　　　　　　　・動的パラメタライズド・クエリ分析ツール - Open 棟梁 Wiki

　　　　　　　　https://opentouryo.osscons.jp/index.php?%E5%8B%95%E7%9A%84%E3%83%91%E3%83%A9%E3%83%A1%E3%82%BF%E3%83%A9%E3%82%A4%E3%82%BA%E3%83%89%E3%83%BB%E3%82%AF%E3%82%A8%E3%83%AA%E5%88%86%E6%9E%90%E3%83%84%E3%83%BC%E3%83%AB

　　　　　・品質に大きく影響しない認識

　　　　　　参照系のDao、SQLをEXCELから生成しても・しなくてもあまり品質に影響しない認識です。

　　　　　　（イベント仕様書がしっかり書かれていれば問題は少ない。ただし、

　　　　　　　スキルに問題がある場合は、SQL定義ファイルを作成するのはアリだと思います）

　　　　　　・開発支援ツールの自動生成方式 - マイクロソフト系技術情報 Wiki

　　　　　　　https://techinfoofmicrosofttech.osscons.jp/index.php?%E9%96%8B%E7%99%BA%E6%94%AF%E6%8F%B4%E3%83%84%E3%83%BC%E3%83%AB%E3%81%AE%E8%87%AA%E5%8B%95%E7%94%9F%E6%88%90%E6%96%B9%E5%BC%8F

　　　　（b）コード変換方式の決定はPJ判断だと思いますが、

　　　　　　コード変換をP層でパフォーマンス良くやる方法はあります。

　　　　　　こちら（WebForm）でやったことですが、

　　　　　　ComboBoxをCustomControl化してRead OnlyのComboBoxを

　　　　　　データバインディング後、テキストボックスに化けさせる方法を採用したことがあります。

　　　　　　OpenTouryoProject/OpenTouryo Wiki

　　　　　　Tutorial_Automatic_Screen_Generation(TableMaintenance).ja

　　　　　　Open 棟梁チュートリアル (テーブルメンテナンス画面自動生成編)

　　　　　　4.2.2 外部キー列のコントロールをドロップダウンリストに変更する

　　　　　　https://github.com/OpenTouryoProject/OpenTouryo/wiki/Tutorial_Automatic_Screen_Generation(TableMaintenance).ja#422-%E5%A4%96%E9%83%A8%E3%82%AD%E3%83%BC%E5%88%97%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%AB%E3%82%92%E3%83%89%E3%83%AD%E3%83%83%E3%83%97%E3%83%80%E3%82%A6%E3%83%B3%E3%83%AA%E3%82%B9%E3%83%88%E3%81%AB%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B

　　　　　　この方法だと、マスタデータからSELECT×１回でデータセットを取得し処理できます。

　　　　　　同様のことが、MVCのHTML Helperでもできるのではないか？と思います。

　　　　　　カスタム HTML ヘルパー (c#) の作成 | Microsoft Docs

　　　　　　https://docs.microsoft.com/ja-jp/aspnet/mvc/overview/older-versions-1/views/creating-custom-html-helpers-cs