0

In all the examples I have seen, ORM's tend to be used directly or behind some kind of DAL repository (presumably so that they can be swapped out in the future).

I am no fan of direct ORM use as it will be hard to swap out, but i am equally no fan of losing the full domain change tracking it provides!

In the past I would have written a data mapper class (Fowler) for each object in my domain, but I have learnt through experience that this CRUD coding drains around 1/3 of my time.

I a realize that changing my data access strategy is rather unlikely (I have never had to do so before) but I am really concerned that by using an ORM directly I will be locking myself into using it until the end of time.

I have been thinking about wrapping the ORM (no decision on the ORM itself yet) in a generic ORM container and passing this around to finder classes for each of the domain objects. However, I am totally unsure what a generic ORM wrapper class would look like!

Has anyone got any real life advise here? Please don't feel it nessecary to sugar coat your answers!!

4

2 に答える 2

0

これらの問題について私よりもはるかに賢い人の方向にあなたを向けるために、Ayendeが彼のブログ投稿で強調しているような一般的なORMラッパーを持つことに関する問題の1つは、DALにデータアクセスをカプセル化するという誤った神話は、異なるORMが本質的にあるということです効果的にカプセル化するには違いが大きすぎる、トランザクション処理の方法が異なるなど。

それに加えて、ORMを切り替える意味はあまりありません。変更があった場合にDALをカプセル化する主な理由の1つは、データベースの切り替えに対処することでしたが、最近のほとんどのORMは、とにかく多くの異なるデータベースで動作できます。

于 2010-09-20T16:47:14.977 に答える
0

リポジトリにはいくつかの機能があります。

  1. これにより、模擬実装による単体テストが可能になります
  2. これにより、ORMの完全な実装をコンシューマーから隠し、セキュリティ機能を実装できます。
  3. これは、ビジネスロジックの抽象化レイヤーを提供します（ただし、これに別のサービスレイヤーを使用する人もいます）。
  4. 必要に応じて、ORMの実装を変更できます。

ORMを一般化するための別のコンテナーは、私には過剰設計のように感じます。ご指摘のとおり、基盤となる実装を変更する可能性はほとんどありませんが、変更する場合は、リポジトリを変更するのが賢明な場所のようです。

于 2010-09-20T16:42:58.043 に答える