言うのは恥ずかしいですが、言わなければなりません。私はORMを扱ったことはありません。NHibernate は .Net 向けの最も成熟した製品と思われるため、実際に検討しています (間違っている場合は訂正してください)。さて、問題は、SqlServer をメインの統合ポイントとする大規模な e コマース/予約システムがあり、かなり多くのビジネス ロジックが sprocs に含まれているということです。現在、明らかに、このアーキテクチャから離れたいと考えており、しばらくの間、少しずつそうしてきました。それで、私の本当の質問は、新しい機能のためにNHibernateを使い始めて、戻ってすべてのレガシーなものをマッピングしないことがどれだけ実現可能かということです. この種の ORM の段階的な導入はサポートされていますか? もしそうなら、それをお勧めしますか?
1428 次
8 に答える
3
レガシーデータベースを使用している場合、ORMツールの使用、構成、保守、および最適化がかなり難しいことに気付くでしょう。NHibernateを使用してドメインモデルを既存のデータベースにマッピングしたときに、多くの問題が発生しました。それらのいくつかは：
モデルオブジェクトを既存のテーブルにマップすることは困難でした（100を超えるテーブルがありました）。ドメインオブジェクトにマップできるようにするには、すべてのテーブルにIDフィールドが必要であるため、NHibernateの要件の一部は非常にわかりにくいものでした。また、多対多の関係をマッピングすることは、把握して使用するのが非常に困難でした。
レガシーデータベースへのマッピングに必要な大量のマッピングXMLを維持することは、開発者にとってフルタイムの仕事になり、特に10人以上の開発者のチームでは非常に困難でした。
データモデルとオブジェクトモデルが常にビジネスと一致するとは限らず、常に調整する必要があるため、複雑さが増すにつれてクエリのパフォーマンスが低下しました。大量のデータ集約コードを作成する必要がありました。たとえば、複数のテーブルを結合したグリッドを表示する必要がある場合、以前は複数のドメインオブジェクトを読み込んでそれらをまとめ、1つのグリッドに表示する必要がありました。そのコードの保守とデバッグは困難でした。
また、匿名クエリを実行する必要がある場合もありました。つまり、オブジェクト全体ではなく、一部のオブジェクトからいくつかのプロパティが必要な場合です。これは、作成、保守、さらには実装するのが非常に難しく、ORMパラダイムに反していましたが、そうするしかありませんでした。
私たちが遭遇したもう1つの問題は、DBAがテーブルをリファクタリングし、それが常にドメインオブジェクトを破壊するため、データベースが絶えず変化していることでした。モデルとテーブルの同期を維持し、アプリが引き続き機能することを確認するのは演習でした。
簡単に言うと...ビジネスに必要なSQLを、構成を気にすることなくUIモデルまたはドメインオブジェクトに直接マップする方法があれば、それはより良いソリューションになるということを学びました。
この経験を経て、OrasisMappingStudioを開発しました。これは、レガシーデータベースおよび既存の.NETモデル/ドメインオブジェクトに対して機能するように特別に設計されたマッピングツールです。SQLクエリを取得し、クエリとオブジェクトのメタデータをグラフィカルに表示し、ドラッグアンドドロップを使用してオブジェクトプロパティとクエリ列の間のマッピングを作成することにより、既存の.NETオブジェクトにそれらをマップできます。このツールは、オブジェクトを読み取るためにマッピングを実行するために必要なすべてのADO.NETコードを自動的に生成します。次に、生成されたコードをDALレイヤーで使用するか、生成されたアセンブリを使用してデータを取得して永続化できます。
ここで試すことができます：OrasisMappingStudio。これは、特にレガシーデータベースを操作するために、パフォーマンスが重要な要件である場合に、開発者が本当に必要と考えるツールです。開発者が開発者向けに作成しているため、Obejctの継承、ネストされたオブジェクト、データ型の変換など、複雑な詳細の一部を処理します。幸運を祈ります。
于 2009-01-26T22:15:19.007 に答える
2
It will depend on how "NHibernate friendly" your current database is. NHibernate likes single column primary keys (if they are all named "id" even better). Most ORM are not very stored proc friendly as far as I know. Did you think about how you are going to define your transfer objects to get data back and forth from the db?
BTW there is nothing to be ashamed of. ORM's are a goot thing but you are right in trying to find the best approach.
于 2009-01-26T21:30:54.167 に答える
1
I haven't personally done this, but you can copy-paste the stored procedures in named queries in your mapping files, and remove them one by one later on.
If you don't have any experience with ORMs, it might probably hard to start learning it in a large legacy project, because you have to discover all the non-standard features of the ORM that you would not use in greenfield projects, or use only once a year. NHibernate has a lot of options to support legacy databases.
When you are prepaired to cross the learning curve and brave enough to start using a new technology you can start with NHibernate, but if you like to learn new technologies step-by-step I would wait with NHibernate until you start a new greenfield project.
于 2009-01-26T21:31:47.843 に答える
1
Any decent ORM tool should support gradual integration. The trick here is to have a clear separation at the DAO level (Data Access Object layer). If you can hide your data access quirks by means of a well-defined API, it shouldn't matter if you are using an ORM or not.
Having that said, the complexity of the ORM introduction is directly related to the complexity of your table models. You can have many different mappings for the same tables, just make sure that you do some trials beforehand in order to know the quirks of an ORM solution like having an object cache, write-behind queries, proxied access and such. The real benefit of an ORM solution is using objects instead of dummy POJO classes. This makes doing changes to the business much more easy than using sprocs or flat objects.
As a side note, I worked on a project where we migrated a whole app in sprocs to java. Although we didn't use a sproc, the real pain was that the sprocs architecture was not well defined, lots of sprocs calling other sprocs made it very hard to migrate just some sprocs at a time.
于 2009-01-26T21:31:56.863 に答える
1
There is nothing within NHibernate that will restrict you from doing this. At some point you will probably want to convert your legacy code to also use NHibernate as you won't see the full benefits of an ORM until you can navigate the relationships between all of your objects.
The biggest challenge with this may be getting your legacy table structures to fit into NHibernate's single table per class methodology. There are ways around this, but it can be tricky. Still, I think it is worthwhile.
于 2009-01-26T21:32:18.280 に答える
1
現在のアーキテクチャから離れることをおっしゃいましたが、レガシー データベースの設計に固執する必要がありますか (たとえば、DBA はデータベースの設計と保守に厳密な責任を負っています)、または現在のデータベースの設計はリファクタリングされていますか (O を考慮して) /R マッパー) も?
現在のレガシー設計から移行するのが難しい場合は、柔軟性の低い Hibernate スタイルではなく、単純な古い T-SQL クエリを使用してエンティティをレガシー データベースに O/R マップするiBATIS SqlMap などの別のものを検討することを検討してください。データをマッピングするための XML/属性。
設計へのアプローチ方法に応じて、独自の抽象DAOファクトリまたはiBATIS DataAccess API (本質的にそれを行い、互換性がある) を使用して、 iBATIS SqlMapと NHibernate を透過的に並べて使用できますNHibernate.)
于 2009-01-27T15:19:53.197 に答える
1
I agree with what Ahmad said, I've faced similar problems in the past. Most of the trouble I had come not from technology itself, but from its adoption by developers, changing to NHibernate implies changes in working habits, to say the least, and this is not always easy.
If you are new to ORM it’s probably better to start a brand new project with it than try to convert a legacy project.
My advice to convert a legacy project to ORM would be to try to use some sort of generating tool like LLBGen or .netTiers or even Linq2SQL. This way you could get a bit more comfortable with ORM without the traumatic rewrite that NHibernate could impose.
于 2009-01-28T16:48:54.107 に答える
0
ストアドプロシージャが「明らかに」悪いのはなぜですか？ストアドプロシージャのビジネスロジックが問題を引き起こしていますか？
Microsoftには、多数の永続化テクノロジ（LINQなど）が利用できるようです。NHibernateと比較してそれらを評価する方法はわかりませんが、マップするのに本当に良いオブジェクトがない限り、ORMはお勧めしません。
于 2009-01-26T21:26:37.620 に答える