ORMツールを使用しない場合に、インフラストラクチャとアプリケーションレイヤーのデータベースアクセスロジックを整理する方法
.NET Coreプロジェクトを作成しようとしていますが、いくつかのガイドに従って基本的なアーキテクチャを作成しています
Entity FrameworkのようなORMを使用していません。マリアデータベースに生のSQLを使用したいので、公式の MySQL Connector を使用しています。データベース接続と依存性注入パーツをセットアップしました。
上記のサンプルリポジトリ（ サンプルはこちら ）を見るとわかるように、データベースアクセスはアプリケーション層で行われ、ビジネスロジックに結合されています。永続層は、データベース構成コンテナのようにのみ機能します。
データベースアクセスロジックを整理する方法のベストプラクティスについて知りたい。
- クエリを実行する前に、接続を開いて、後で閉じる必要があります。 1つの接続で複数のクエリを起動できるので、アプリケーションコマンド/クエリでこれを行う必要がありますか？
- データベースロジックをどのように構成すればよいですか？ SQLクエリとデータベース結果からドメインオブジェクトへのマッピングを処理するSQLステートメントごとに1つのファイルを作成する必要がありますか？
視覚的な目的のためにサンプルのフォルダー構造も提供できればすばらしいと思います。
Entity FrameworkのようなORMは、 Raw SQLクエリ の使用を妨げません。
Entity Frameworkが好みに合わない場合は、 Dapper またはいくつかの異なるマイクロフレームワークの使用を検討してください。これらのツールは、データベースへの接続とクエリパラメータの管理の煩わしさの多くを解消し、 Little Bobby Tables に遭遇することなく、SQLクエリの作成に時間と労力を集中させることができます。 。
ORMは Data Access Layer としても機能し、 [〜＃〜] crud [〜＃〜] 操作を抽象化して、アプリケーションの興味深いサービス層。独自のデータアクセスレイヤーを作成したい場合でも、そうすることができます。データベースのテーブルごとに1つのクラスと4つのメソッド（作成、読み取り、更新、削除）が必要です。
接続の管理方法はさまざまです。 MariaDBが接続を開くことができる速さ、および接続をキャッシュするかどうかに応じて、クエリごとに接続を開くことをお勧めします。 DDDを実践している場合は、 Aggregateレベル でも実行できます。または、接続を開いてそのままにしておくこともできます。それは本当にあなたのアプリケーションとあなたがそれをどうしたいかによります。
SQLステートメントごとに1つのファイルが少し聞こえます。エンティティークラス内にSQLステートメントを配置してみてください。隠しておくのにとても便利な場所です。
フォルダ構造は主に好みの問題です。 「標準」はありません、そして誰もが異なる方法で行います。
さらに読む
EA of PAA：Data Mapper
EA of PAA：Repository
EAAのP：サービスレイヤー
ベストプラクティスを探しているのであれば、リンクされているリソースは、現時点での業界の最悪のプラクティスの要約です。
ビジネス関連の知識がなく、維持管理が困難な貧血中心の「ドメイン」。動作はまったくなく、技術的な編成とパッケージの命名。完全な手続き型設計への完全な回帰。サンプルアプリはCOBOLで記述されている可能性があり（違反はありません）、デザインにまったく違いはありません。
そうは言っても、一般的にORMを廃止することは良いアイデアであり、より良い設計決定を行うのに役立ちます。しかし、賢明なアーキテクチャに到達するには、ロジックをそれらが属するオブジェクトに戻す必要があります。次に、実行できる複数のオプションがあります。
- オブジェクトの外部で実行されるトランザクションタイプのパラメータを渡しますが、オブジェクトはそれにデータベース操作を追加できます。 （したがって、開閉はオブジェクト自体の問題ではありません）
- 他のオブジェクトと組み合わせて後で実行できるトランザクションタイプのオブジェクトを返します。 fpでは、これは「モナド」になりますが、これは「他の人と組み合わせることができる」という単なる空想的な言葉です。
- 別個の「持続性」構造はなく、ビジネス構造のみがあり、持続性はその機能の1つです。