すべてのレイヤー BLL 、DAL 、および UI でクラス (コンクリートまたはインターフェイス) を共有する必要があります。
これは本当に悪い習慣ですか？
私は、DAL メソッドからデータ テーブルを返すのではなく、BLL が直接使用できるオブジェクトを返すことを好みます。
すべてのレイヤーが知っておくべきクラスを含む別の VS プロジェクトが必要です。
例: すべてのレイヤーが認識すべきロット クラスを定義したいと考えています。UI は、ユーザーが処理するロットを表示または送信できるようにするために、ロット クラスを受け取ることができる必要があります。また、DAL は、ロット クラスを使用してデータベースにクエリを実行し、それらを返すことができる必要があります。一方、BLL はこれらのロットを取得し、ビジネス ルールを適用する必要があります。
これが完全に間違っている場合、代替手段は何ですか?
すべてのレイヤーBLL、DAL、およびUIでクラス（コンクリートまたはインターフェイス）を共有する必要があります。
クラスの種類によって異なります。共通のドメインエンティティにアクセスするためにそれらすべてが必要な場合は、必ず。
重要な部分は、それらのレイヤーがそれらのクラスで何をできるようにするかです。クライアント/UIレイヤーは、一元化されたビジネスロジックを経由せずに、ドメインエンティティを変更（および永続化）できないようにする必要があります。つまり、共通のエンティティやインターフェースなどを共有することはできますが、UIからDALにアクセスすることはできません。
一般的なアプローチは次のようなものです。
UI-> BLL-> DAL->永続ストレージ（DB、ファイルなど...）
これらの各レイヤーは、共通クラスにアクセスできます。UIがDALに直接アクセスできない限り、問題はありません。これにはいくつかのオプションがあります。
最終的には次のようになります。
UI->サービス->BLL->DAL->永続ストレージ（DB、ファイルなど）
MartinFowlerによるPatternsofEnterpriseApplicationArchitectureを強くお勧めします。これは、アプリケーションを階層化するための優れた基盤を提供します。
DALメソッドからデータテーブルを返すのではなく、BLLが直接使用できるオブジェクトを返すことを好みます。
良い考えです。ここで、 ORMのアイデアが役立ちます。DALは通常、DBと通信する方法を知っており、DALはDB固有の構造をドメインモデルに変換する方法も知っています。ドメインエンティティは、DALに出入りします。DAL内では、データを永続化するときにドメインエンティティがDB固有の構造に変換されます。そして、その逆が起こります。BLLがデータを要求すると、DALはデータを取得し、それをドメインエンティティに変換してから渡します。