タグ付けされた質問 「nhibernate」

NHibernateユーザープログラマーが犯す最も一般的な間違いとアンチパターンは何ですか？それらが悪い習慣である理由を説明するか、さらに読むためにリソースへのリンクを提供してください。 例えば： 新しいNHibernateプログラマに共通するアンチパターンの1つは、ORMスタイルの1回ではなく、アイデンティティ/ネイティブPOIDを使用することです。詳細はこちら...

28 nhibernate 

現在、すぐに使用できるオブジェクトリレーショナルマッパーを使用するか、独自のロールを作成するかを選択できる状況にあります。 残念ながら、データ層とビジネス層が一緒にマッシュされたレガシーアプリケーション（ASP.NET + SQL Server）があります。システムは、データアクセスに関して特に複雑ではありません。相互に関連するテーブルの大規模グループ（35〜40）からデータを読み取り、メモリ内で操作し、サマリー形式で他のテーブルに保存します。現在、いくつかのリファクタリングの機会があり、データアクセスを分離して適切に構造化するために使用する候補技術を検討しています。 どんなテクノロジーを選択したとしても、 ドメインモデルに、持続性に無知なPOCOオブジェクトがある モックアップされた基礎となるデータソースに対してドメインモデルオブジェクトをユニットテストできるようにする抽象化レイヤーがあります パターンとフレームワークなどに関しては、明らかにこれに関するものがたくさんあります。 個人的には、EFをADO.NET Unit Testable Repository Generator / POCO Entity Generatorと組み合わせて使用​​することを推進しています。これはすべての要件を満たし、Repo / UnitOfWorkパターン内に簡単にバンドルでき、DB構造は適度に成熟（既にリファクタリング済み）であるため、モデルに毎日変更を加えることはありません。 ただし、グループの他のメンバーは、独自のDALを完全にゼロから設計/ローリングすることを提案しています。（カスタムDataMappers、DataContexts、リポジトリ、どこでもインターフェイス、具体的なオブジェクトを作成するための依存性注入過剰、カスタムLINQから基になるクエリ変換、カスタムキャッシングの実装、カスタムFetchPlanの実装...）狂気として私。 投げかけられた議論のいくつかは、「少なくとも、私たち自身のコードを制御できるようになる」または「以前のプロジェクトでL2S / EFを使用したことがあり、頭痛に過ぎなかった」です。（私は以前に実稼働環境で使用したことがありますが、問題はごくわずかであり、非常に管理しやすいものでした） だから、あなたの超経験豊富な開発者/アーキテクトには、この製品を完全な災害になると思われるものから遠ざけるのに役立つかもしれない知恵の言葉があります。EFの問題をかわすことで得られる利益は、車輪の再発明を試みることで、すぐに失われると思います。

20 design-patterns  database-development  entity-framework  nhibernate 

私はあなたの最初のNHibernateベースの公式アプリケーションを読んでいます。 チュートリアルはわかりやすくてわかりやすいですが、Repositoryパターンを使用する理由を知りたいと思います。 様々でAdd、Update、RemoveのメソッドProductRepositoryの実装は、コードはほとんど同じである-彼らはすべてのトランザクションを使用している、との違いは、「肉」、すなわちコールであるsession.Saveint型Add、メソッドsession.Deleteにremove方法。（ページはHTMLのアンカーを欠いていますが、のような関連するコードのページを検索することができpublic void Remove、public void Add） そのコードは「間違っていると感じる」だけです。 作者がリポジトリパターンを使用しているのはなぜですか-NHibernateを使用するためのデモンストレーションのためだけなのか、それとも必要なのか、またはその他の理由がありますか？ 追伸 私のバックグラウンドはActiveRecordを使用したRuby on Railsからのものですので、NHibernateがどのように機能するか、またはどのように使用されるかを理解しようとしています。

13 c#  .net  nhibernate 

私は最近、エンティティフレームワークのような強力なORMでリポジトリパターンを使用することに対して多くの議論を読みました。リポジトリパターンは作業単位機能とともにリポジトリに似た機能を組み込んでいるからです。 単体テストのような状況でパターンを使用することに対するもう1つの論点は、より汎用的な実装がIQueryableを活用するため、リポジトリパターンは漏れやすい抽象化であるということです。 リポジトリパターンの使用に反対する議論は私には理にかなっていますが、提案された抽象化の代替方法はしばしば混乱を招き、問題と同じくらいやり過ぎです。 Jimmy Bogardsのソリューションは、抽象概念を吹き飛ばすことと、彼自身のアーキテクチャを導入することの組み合わせのようです。 https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/ リポジトリが不必要になっている別の例....しかし、私のアーキテクチャを使用してください！ http://blog.gauffin.org/2012/10/22/griffin-decoupled-the-queries/ 別の... http://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework 私は、それ自体が設計されていない「過度に複雑な」リポジトリパターンアプローチの明確な代替物や代替物を見つけていません。

12 domain-driven-design  entity-framework  orm  nhibernate  repository-pattern 

私は過去にMDA（モデル駆動型アーキテクチャ）ツールを使用しましたが、UMLを介してモデル化し、これにより、とりわけビジネスエンティティ（ドメインモデル）とORM（マッピングなど）が生成されました。 ドメインで動作するビジネスコードとサービスの多くはモデルの一部であり、リポジトリはビジネスエンティティを返していました（そのため、別のORMに切り替えることはできませんでした（望んでいなかった））。 しかし、今はプロジェクトを始めており、DDDについて考えたいと思います。 これまでのところ、ビジネスロジックをドメインモデルに入れ、リポジトリを介してORM（どちらを選択した場合でも）で作業するように感じています。ただし、アプリケーションのORM部分に引き続きMDAツールを使用したい場合、ここで作成されたモデルは非常に貧弱です（つまり、ビジネスロジックが含まれていません）。同様に、ORMにエンティティフレームワーク（.net）またはNHibernateを使用した場合、それも貧血モデルになります。NHibernateをそのまま使用した場合、ビジネスロジックをどこに置くかわかりません。 私はこのように考えるのは正しいですか、つまりDDDではドメイン内のすべてのビジネスロジックを使用し、リポジトリ経由で永続化するためにORMを使用するだけですか？

10 orm  entity-framework  domain-model  nhibernate  domain-driven-design 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 ビジネスアプリケーションの作成を開始してから（高レベルのフロントエンドまたは非常に低レベルのシステムプログラミングを行う前に）過去2年間で、データセット、linqからsql、そして現在はエンティティフレームワークを学びました。次に見る論理的なものはNHibernateのようです。 私が最終的にEFに到達した理由は、（1）デザイナーによるサポートが最も優れていること、（2）マイクロソフトによって最もサポートされていることです。 私がNHibernateに興味を持っている理由（これらには前提の要素があります）は次のとおりです。（1）MSがデータアクセステクノロジーをチャーンするほど速く、まったく異なるものに取って代わられない可能性があります。それが何をするためのフロントランニングツールと（3）それはかなり安定していて、かなり長い間遡ることができるように見えます。 誰かが2つの比較を発表しましたか？特定の種類のアーキテクチャでは、どちらが優れているか？それとも、スタイルと好みの問題だけですか？

8 c#  entity-framework  nhibernate