私は次のプロジェクトにNetTierを使用しています。NetTierへの変更に関するアドバイス
問題は です。スキーマ内のすべてのテーブルにAccountIdフィールドがあります。 DALへのリクエストがあるたびに、AccountIdが渡されてクエリのフィルタとして使用されることが必要です。
このパラメータを使用した余分なオーバーロードが生成された場合は許容されます。
私はこの機能が組み込まれていないと思うので、追加するテンプレートの変更をどこから始めるべきだと思いますか？
生成されるクラスの迷路をあなたが知っていれば、NetTiersテンプレートを変更することは難しくありませんが、通常は非常に面倒で非常にエラーがあります。それ以外の場合はすべてのテーブルでたAccountId列を持っている意味がありません -
私の最初の仮定は、あなたがオフに生成されているデータベースがあるのいずれかのみいくつかのテーブルを持っているかdenormalisedされていることです。後で、構造を正規化することができない場合、追加のAccountIdフィルタを使用してデータベースの外部キー（DeepLoadsを含む）に基づいて構築されたすべてのナビゲーションプロパティを取得することはかなり大きな変更になると考えられます。
さらに、AccountIdを含むオーバーロードを追加することは許容される解決策であると言及します。
：しかし、これは任意のDALの消費者へ たAccountIdパラメータを必要としない既存のNetTiersオーバーロード...とにかくを残して、ここにあなたが変更を検討する必要がある区域の一部の要約です
AccountIdを指定せずにクエリを正常に実行できないようにするには（例えば、GetPaged @where節を介してデフォルトのDALを迂回する方法がたくさんあります）、SQLレイヤーで変更する必要があります。これらのテンプレートは/DataAccessLayer.*Client/フォルダにあります。 SQL Serverを使用していると仮定すると、Sql（/DataAccessLayer.SqlClient/StoredProcedureProvider.cst）を生成するファイルは、@AccountIdパラメータが常に渡されるように変更できます。
これは、/DataAccessLayer.SqlClient/SqlEntityProviderBase.generated.cstと/DataAccessLayer/EntityProviderBaseCore.generated.cstなどの関連ファイルの変更につながり、おそらくは/DataAccessLayer/EntityProviderBaseCoreClass.generated.cstになります。
これは、EntityBaseCore.generated.cstとEntityInstanceBase.generated.cstのようなエンティティレイヤ（/Entities/）の変更につながります。
私の一般的なアドバイスはNetTiersとCodeSmithが数年前にDALSを構築するための最適なツールでしたが、私はこれらの日、この道を行くお勧めしなかったことです。 MicrosoftのEntity FrameworkとオープンソースのNHibernateの進化により、（たとえコード生成レベルであっても）データアクセス用配管層に深く掘り下げる必要はありません。
私の質問ではなく、ネットティア全体をどこから始めるべきかについての優れたヒント。ありがとう –