データベース層に接続して対話する方法は多数あります。たとえば、Javaでは、一般的な使用法は、raw SQLのJDBC呼び出し、オブジェクトリレーショナルマッパー、JDBCTemplate（Spring）、ストアドプロシージャなどです。
あなたの言語では、どのオプションがあなたの好みであり、その理由は何ですか？いつ他の人を考慮しますか？
2927 次
16 に答える
4
ORMは毎回、データベースについて考える必要が少ない方がよいでしょう。
于 2008-08-11T19:08:47.250 に答える
4
私は物事を行うための3+1層の方法が本当に好きです。UI用、ビジネスロジック用、およびデータの永続化用の1つの層。あなたが最後に言うのは？ドメインオブジェクトとインターフェイス。これにより、メイン層の1つまたは2つとドメイン「層」をロードできるようになり、コードが機能するはずです。
これは、依存性の注入と制御の反転の原則に大きく依存しています。データ/永続層は2つのことだけを行います。データを作成、読み取り、更新、削除し、ドメインオブジェクト形式にマッピングします。
UI層は正反対です。これは、ユーザーが関係できる方法でデータを表示および受信し、その出力/入力をドメインオブジェクト形式との間でマッピングします。
ビジネスロジック層は、1つのことを知っている必要があります。ビジネスの論理。データがどこから来たのかは気にせず、データ層がどこにデータを置いているのかも気にしません。引き落とされたばかりのアカウントにフラグを立てる必要があることを知っています。それを物理的に行う方法は、実際にはその仕事の一部ではありません。
ドメインオブジェクト自体にはロジックがなく、階層間でデータを渡すための単なるコンテナです。これは、依存関係についてまったく考える必要なしに、ドメインオブジェクトとインターフェースをロードできることを意味します。
結局のところ、私は明確に分離された層を持つかなり明確なコードベースを持っていると感じています。また、いくつかの厳密なインターフェイスと優れた基本クラスを使用すると、ほとんどのコーディングは、Xが発生したときに何をすべきかをソフトウェアに指示するだけです。どうあるべきか。
</rant>
編集：ああ、そうだ。これは、LINQ、SubSonic、およびその他のORMの両方に当てはまります。
于 2008-08-11T19:24:44.113 に答える
3
Ruby on RailsのActiveRecordは、これまでに見たすべてのものでフロアを一掃します。LINQの方が良い場合もあるように見えますが、ActiveRecordは非常に柔軟性があります。
于 2008-08-12T00:42:06.237 に答える
2
私はビジネスオブジェクトモデルレイヤー（オブジェクトとオブジェクトのコレクション）を構築することを好みます。
データベースと対話する機能を各オブジェクト/コレクションに組み込みます（SQL Serverの場合、System.Data.SqlClientを使用します）。このパターンは、SQL Server、MySQL、およびOracleに使用しました。
次に、アプリケーションコードのオブジェクトを操作します。
データベースをオブジェクトに抽象化することで、バックエンドデータベースに関係なくアプリケーションコードの一貫性が保たれます。
于 2008-08-11T19:07:35.413 に答える
2
LINQはこれから私のために行く方法です
于 2008-08-11T19:09:31.900 に答える
1
ORMは確かに素晴らしいです。
私はPython内で作業するときにSQLAlchemyを使用します-これは私が遭遇したほぼすべてのDBMSで動作します。
MacOS Xの軽量データ駆動型アプリケーションには、Xcodeを介してアクセスできる優れたデータモデリングツールを備えたCoreDataを使用します。
これらは両方とも、正しく行われたORMが優れていることを示しています。私はEJBの成功と楽しみが少なかった。
于 2008-08-11T23:35:12.160 に答える
1
私はまだLINQの世界に慣れていませんが、VisualStudioがXSDデータセットを使用して行ったDataTable/TableAdapterクラスが大好きになりました。データベーススキーマを作成した後、数回ドラッグアンドクリックするだけで、強く型付けされたDataSet / DataTableオブジェクトができ、すべてのCRUDステートメントのストアドプロシージャに対してパラメーター化されたクエリを使用するアダプターメソッドができました。テーブルに直接関連付けられていないいくつかのプロシージャ用のクエリテーブルアダプタも作成します。
ああ、まだストアドプロシージャを作成しておらず、テーブルしかない場合は、ウィザードがプロシージャまたはアドホックSQLステートメントを作成します。
これはVisualStudio2005からリリースされており、新しいWebアプリでの「構造」時間を大幅に短縮し、ビジネスとプレゼンテーションロジックにさらに集中できるようになりました。
于 2008-08-11T23:42:06.933 に答える
1
アプリケーション内の特定の状況に何が適しているかに応じて、混合アプローチを使用します。
- 表示する情報やユーザーが更新するページに相当する情報を読み取るときは、Hibernate を使用します
- 更新のバッチを処理したり、ほとんどのデータが既にデータベースにある場所を要約したりする場合 (例: 1 日の終わりの処理)、PL/SQL を使用します (そしてセットで考えようとします)。
- ユーザーが検索を実行したり、概要レポートを実行したりすると、ibatis sqlmaps を使用して SQL を構築し、関心のあるフィールドのみを返します (すべての列ではなく、不要な子行も含まれていません)。
- 本当に迅速に実行する必要があるものはすべて、最適なアプローチを使用します
これは、Java/Oracle の場合です。
于 2008-10-09T09:15:34.553 に答える
0
私のお気に入りの方法は、オブジェクト抽象化レイヤーを作成することです。理想的には、これはSQLで動作する唯一の場所です。しかし実際には、オブジェクトはSQLのようなこともする必要がある場合があります。しかし、オブジェクトの外側には何もありません。
これまでのところ、利用可能なものが扱いにくい、遅すぎる、または大きすぎるため、私はそのようなレイヤーを自分で作成しました。
于 2008-12-09T06:13:37.593 に答える
0
C＃では、新しいものについてはLINQ to SQLが大好きですが、.NET 2.0でC＃を使用している場合は、 .netTiers + CodeSmith Generatorを使用して、データベースへの迅速でダーティなデータレイヤーを取得するのが本当に好きです。
于 2008-08-12T00:32:52.183 に答える
0
ActiveRecordは、Fowler のPatterns of Enterprise Architectureで最初に (私が思うに) 文書化されたパターンです。Railsのコア技術として有名ですが、Ruby以外の言語でも実装されていると思います。いずれにせよ、これはデータベースのきちんとした抽象化です。しかし、それは私だけかもしれません。
しかし、(今は不機嫌そうな老人の帽子をかぶって) 世界中のすべての ORM は、SQL の十分な知識に代わるものではありません。SQL の知識がなければ、RDBMS へのアクセスがまったく許可されているのを見るのは本当に好きではありません。
于 2008-08-12T08:55:03.917 に答える
0
私は休止状態が大好きです:)
学習曲線があることは知っていますが、一度マスターすると、非常に素晴らしいものになります.
言うまでもなく、.NET 3.5 SP1 の新しいEntity Frameworkを手に入れるのが待ちきれません(すでに利用可能であることはわかっていますが、XML を入力するのが少し面倒です :) )。
于 2008-08-12T08:05:26.107 に答える
0
Oracle.OleDBProvider を介して、Delphi と Oracle Data Access Components (ODAC) および ADO を使用します。
于 2008-10-25T05:40:29.383 に答える
0
お気に入りの方法は、GemStone オブジェクト リポジトリで Smalltalk を使用することです。なんで？対処するORMの問題はありません。雇用主によって強制または脅迫された場合にのみ、他のことを検討します。
于 2008-12-09T06:07:36.250 に答える