問題タブ [data-access]

.NET アプリからストアド プロシージャを呼び出しています。proc は Varchar2 型の out パラメータを返します。out パラメータをフェッチするために、パラメータを OracleParameter としてコマンドに渡します。

proc を実行すると、エラーが発生します

私たちのソフトウェアは、ASP.NET と Oracle をデータベースとして使用するカスタマイズされた人事管理システム (HRMS) であり、現在、独自のデータベースを持つ複数のテナントをサポートする製品にするために実際に動いています。

私たちのオプション:

1. NHibernate を使用して、複数のデータベースと OO の使用をサポートします。しかし、NHibernate の学習曲線と直面した問題に関連する懸念があります。

2. ストアド プロシージャを使用して引き続き Oracle と連携する一般化された DAL を作成し、ツールを使用してそれを SQL Server や MySql などの他のデータベースに変換します。単一のスクリプトのデータベースに依存する複数のバージョンをサポートする必要があることに関連するリスクがあります。

3. サービスとしてのソフトウェア (SaaS) を提供し、ビジネスの方法を維持します。ただし、クラウドやその他の SaaS ビジネス モデルを望まない、または信頼しないクライアントがいる可能性があります。

これを念頭に置いて、最良のデータ アクセス レイヤー手法は何ですか?

大規模な ASP.NET MVC アプリケーションのビジネス レイヤーとデータ レイヤーを作成しようとしています。この規模のプロジェクトを試みるのはこれが初めてなので、本を何冊か読んで、物事を適切に分離することに細心の注意を払っています。通常、私のアプリケーションではビジネス ロジックとデータ アクセス レイヤーが混在し、複数のビジネス エンティティが 1 つのクラス内で絡み合っています (追加する場所を見つけようとしているときに、何度か混乱しました)。

私が読んできた内容のほとんどは、ビジネス レイヤーとデータ レイヤーを分離することです。これはすべて問題ないように思えますが、いくつかのシナリオでこれを行う方法を正確に視覚化するのに苦労しています. たとえば、管理者が新しい製品をシステムに追加できるようにするシステムを作成しているとします。

次に、リポジトリを作成してデータ アクセスを分離します。

製品の名前に少なくとも 4 文字を要求したいとしましょう。これをきれいに行う方法がわかりません。

私が持っていた 1 つのアイデアは、Name の set プロパティを拡張し、4 文字の長さの場合にのみ設定することでした。ただし、 Product.Name != 渡されたものを除いて、製品を作成しているメソッドが名前が設定されなかったことを知る方法はありません。

私が持っていた別のアイデアは、それをリポジトリの Add() メソッドに入れることですが、その後、ビジネス ロジックとデータ ロジックがすぐそこにあります。つまり、Add 呼び出しが失敗した場合、ビジネス ロジックまたは DAL が失敗したためです (また、モック フレームワークを使用してテストできないことも意味します)。

私が考えることができる唯一のことは、レポジトリの Add() メソッドから呼び出される第 3 層に私の DAL を配置することですが、私の本やweb (少なくとも私は見たことがある)。また、それが必要かどうか確信が持てない場合、ドメイン モデルの複雑さが増します。

もう 1 つの例は、名前が 1 つの製品だけで使用されるようにすることです。これは、Product クラス、ProductRepository の Add() メソッド、またはどこに入れますか?

補足として、私は ORM として NHibernate を使用する予定ですが、(理論的には) 必要なことを達成するために、TDD はすべてを分離できるはずなので、使用している ORM は問題ではありません。

前もって感謝します！

現在、外部キーを定義せずに大規模なデータベース (約 500 テーブル) を使用しています。

私の質問は、すべて手動で行うことなく、エンティティ フレームワーク (バージョン 1 または 2) 内で関係を設定する簡単な方法はありますか?

また、一部のテーブルには複雑な関係タイプがあります。たとえば、顧客には親 ID がありますが、これは同じテーブル内の別の顧客 (customerID) にリンクするか、アカウント テーブル内のアカウント (accountID) にリンクすることができます。この種の関係はエンティティ フレームワークで可能ですか?

これが不可能な場合、または Enitity Framework の代替ソリューションについて誰かが意見を持っている場合、私はアイデアを受け入れます。nHibernate またはアクティブ レコードはより良いソリューションでしょうか? それとも、独自のビジネス オブジェクトとデータ アクセスを作成する方が簡単ですか?

乾杯

サイモン

データ アクセスまたは CRUD に関する Visual Basic 6 (Visual Basic .NET ではない) のチュートリアル (できれば Web サイトまたはブログ) を知っていますか? 私が探している口径と深さは、次のサイトに似ています。

ASP.NET のデータ アクセス チュートリアル

http://www.asp.net/learn/data-access/

上記のサイトは Web アプリケーション用ですが、WinForm VB6 のチュートリアルを探しています。

お時間をいただきありがとうございます。

3つのプロパティを持つ単純なオブジェクトがあります。これは、3つの列を持つテーブルにリンクし、2つの列が主キーです（一方はもう一方は日時です）。

nhibernateをクエリしようとすると、次のエラーメッセージが表示されます。

プロパティを解決できませんでした：invdate of：Models.Invoice

マッピングの設定で簡単なことを見逃したことがありますか、それともクエリを間違って行っていますか？

オブジェクトコード：

マッピングコード：

クエリでinvdateへの参照を削除すると、これは正常に機能します。

前もって感謝します。

アプリケーションを構築していて、データベースへの1回のラウンドトリップに複数のクエリをバッチ処理したいと考えています。たとえば、1つのページにユーザーのリスト、グループのリスト、および権限のリストを表示する必要があるとします。

だから私はprocs（または "select * from Users"のような単純なSQLコマンド）を保存しました、そしてそれらのうちの3つを実行したいと思います。ただし、この1ページにデータを入力するには、3回往復する必要があります。

これで、単一のストアドプロシージャ（ "getUsersTeamsAndPermissions"）を作成するか、単一のSQLコマンド "select * from Users; exec getTeams; select *fromPermissions"を実行できます。

しかし、1回の往復で3つの操作を実行するように指定するより良い方法があるかどうか疑問に思いました。利点には、単体テストが容易になることや、データベースエンジンがクエリを並列化できることが含まれます。

C＃3.5とSQLServer2008を使用しています。

SOA WCF システムにはデータ アクセス サービスがあります。このサービスは、「システム全体」のデータベース テーブルに対する CRUD (作成、更新、削除) 操作を実行する役割を担い、クエリのこのデータのソースでもあります。DAS の制御下にあるテーブルにアクセスしたいシステム内の他のサービスは、DAS にアクセスして取得または変更する必要があります。Entity Framework を使用し、この DAS 用に独自の POCO 状態追跡システムを構築しました。

データベースには、単一のサービスに属する他のテーブルがあり、データを独自に使用するためだけに保存​​します。つまり、クラッシュして再開した場合にアクセスできる状態情報、またはビジネス情報の記録です。複数のサービスが 1 つのテーブルにアクセスできないという規則があります。そのため、複数のサービスが必要とするデータは DAS に格納されます。

真実は、直接テーブルにアクセスするのではなく、なぜデータ アクセス サービスが良い考えなのか、私は本当に理解したことがないということです。DAS はデータベース更新のために POCO グラフを返すことができないため (一度に 1 つの POCOS のみ)、DAS が実際にはデータを必要とする別のサービスのクライアントである場合にも問題があります。それから...循環依存。

なぜDASを気にするのですか？SOAに関してDASが重要なのはなぜですか? ここで何が欠けていますか？単一の制御ポイント?

すべてのテーブルが DAS の一部であるとは限らず、一部のサービスが独自の「プライベート」テーブルを持っていることも、SOA 設計上の欠陥ですか?

この歓迎についての議論。

私は、既製の優れた代替品がない場合に、独自のビジネス データ アプリケーションを作成する会社にいます。ほとんどの場合、それは - ログイン画面 - ほとんどが SQL Server テーブルの視覚化であるいくつかの画面 - いくつかのレポートです。

以前は、MS Access を使用していました。これらは正確には最も優れたコーダーではありませんが、ほとんどの場合、データベースを構築する方法と UI に必要なものを理解しています。

アプリに突っ込んで使い始めることができる、一般的なログイン画面、メニュー画面などが必要です。これにより、開発速度と保守性が向上します。

もちろん、これを行う方法は複数あり、問題の核心はデータ アクセスにあるようです。オプションは次のとおりです。

1）ASP.NETのビデオのようなGUIデータセット/テーブルアダプターは、その方法を示しています。私たちの何人かはこれをたくさんやっています。開発速度に適しています。気付かないうちにデータ接続が変更されることがあります。巨大なメソッド シグネチャ (挿入または更新のフィールドごとに 1 つのパラメーター) は、エラーが発生しやすくなります。パラメータが正しく検出されないことがあります。動的パラメーター (オプションのフィルターを使用したレポートなど) は非常に困難です。

2) 非常に構造化された n 層スタイル。たとえば、グリッドのデータソースはオブジェクトのコレクションです。プレゼンテーション レイヤーは、オブジェクト A の静的メソッドを呼び出します。このメソッドは、データベースから返される行ごとに A をインスタンス化するデータ アクセス レイヤー メソッドを呼び出します。A には、テーブル内のすべてのフィールドの get/set メソッド、内部変数、およびコンストラクター変数が必要です。各フィールドは何度も入力されます。何にも縛られているものは何もありません。これほど単純なアプリにはやり過ぎの可能性があります。

3) 汎用テーブルは、フィールドのリストをループして UPDATE ステートメントと INSERT ステートメントを動的に作成する汎用関数ですべてを駆動します。選択は主に SELECT * タイプのものです。急速な開発ですが、強力なタイピングの欠如は私を怖がらせます. SQL インジェクションの地雷はどこにでもあるように見えますが、それを避けるために必要なのは引用符を 2 倍にすることだけだと確信しています。

他にもオプションがあるはずですが、それらが何であるかはわかりません。私/私たちに何か提案はありますか?

このチャートは私がフォローしているブログに何度もリンクされており、ルーブがそれを取得していないように感じます。それで、ここで手足に出て、このコミュニティに尋ねてください。こちらのブログ投稿からこのグリッドについて説明してください。