ネッティアへの変更に関するアドバイス

Question

私は次のプロジェクトにネットを使っています。

問題は次のとおりです。私のスキーマのすべてのテーブルには、フィールドアカウントがあります。 DALへのリクエストごとに、AccountIDが渡され、クエリのフィルターとして使用されるという要件であることを望みます。

このパラメーターを使用する追加の過負荷が生成された場合、それは許容されます。

この機能は組み込まれていないと思われます。そのため、テンプレートの変更からどこから始めて追加するかについてアドバイスを提供できますか？

Answer 1

Nettiersテンプレートを変更することは、生成するクラスの迷路の周りの方法を知っていれば難しくありませんが、通常は非常に退屈で非常にエラーが発生しやすくなります。

私の最初の仮定は、あなたが生成しているデータベースはいくつかのテーブルしか持っていないか、非正規化されているかのどちらかです - そうでなければ、それは意味がありません アカウントID すべてのテーブルの列。それが後のものであり、構造を正規化できない場合、データベースの外部キー（ディープロードを含む）に基づいてすべての構築されたITナビゲーションプロパティを追加することはかなり大きな変化であると考えています。 アカウントID フィルター。

また、あなたは含む過負荷を追加することに言及します アカウントID 許容可能なソリューションになります。ただし、これにより、既存のネッティアが必要としない過負荷を残します アカウントID DAL消費者へのパラメーター...

とにかく、ここに変更を検討する必要がある領域のいくつかの要約があります。

• AccountIDを提供せずにクエリを正常に実行できないことを確認するために（デフォルトのDALを介してデフォルトのDALを回避する方法がたくさんあります GetPaged @where たとえば、節）、おそらくSQLレイヤーで変更を行う必要があります。これらのテンプレートはにあります /DataAccessLayer.*Client/ フォルダー。 SQL Serverを使用していると仮定すると、SQLを生成するファイル（/DataAccessLayer.SqlClient/StoredProcedureProvider.cst）@AccountIDパラメーターが常に渡されるように変更できます。

• これにより、次のような関連ファイルが変更されます /DataAccessLayer.SqlClient/SqlEntityProviderBase.generated.cst と /DataAccessLayer/EntityProviderBaseCore.generated.cst そしておそらく /DataAccessLayer/EntityProviderBaseCoreClass.generated.cst.

• これにより、エンティティレイヤーの変化が発生します（/Entities/） そのような EntityBaseCore.generated.cst と EntityInstanceBase.generated.cst.

私の一般的なアドバイスは、数年前にダルを建設するために選択したツールでしたが、最近はこの道を進むことをお勧めできなかったということです。 Microsoftのエンティティフレームワークとオープンソースのnhibernateの進化により、データアクセス配管層の奥深くに手をつなぐ必要はもうありません（コードジェネレーションレベルのみであっても）。