2

このように部分クラスを使用してBLLとDALを実装しても大丈夫ですか？

 namespace BLL
{
   partial class Employee
  {
    public string EmpID { get; set; }
    public string EmpName { get; set; }

     public List<Employee> GetListOfEmployees()
     { 
       return DAL.Employee.GetListOfEmplyee();
      }

     }
  }

namespace DAL
{
 partial class Employee
 {
    public static List<Employee> GetListOfEmployees()
    {
        //DATA ACCESS
        var emps = GetEmployeesFromDb(); // fetch from db
        return emps;
   }
 }
}

または他の提案？前もって感謝します。

4

7 に答える 7

3

クラスを作成して何を達成しようとしているのかは不明ですpartial。部分クラスは、1 つのクラスを複数のファイルに分割する必要がある場合に便利です。通常は、1 つまたは複数の部分が機械で生成されるためです。この場合、マシンが生成した部分と人間が編集した部分を分離すると、一方の変更セットが他方を上書きしたり壊したりしないようにするのに役立ちます。

あなたの例では、2 つのクラスが異なる名前空間にあるため、パーシャルを使用してもあまり効果がありませんEmployee。それらは単一の実装にマージされません。

解決しようとしている問題を説明できれば、質問に対するより良い答えを得ることができるかもしれません。

于 2010-09-16T14:33:03.060 に答える
1

そのように部分クラスを使用することはできません.BLL.Employeeは、異なる名前空間にあるため、DAL.Employeeとは異なるクラスです。他の部分のない 2 つの部分クラスしかありません。

それらが同じクラスを表していたとしても、両方が同じシグネチャを持つメソッドを定義することはできません。

于 2010-09-16T14:33:34.527 に答える
1

多くは好みによるものですが、個人的には、Employee/EmployeeCollection 作成用のFactoryクラスを作成し、オブジェクト自体には入れません。オブジェクトに入れたら、オブジェクト作成メソッドを静的にして、実際のオブジェクトを作成するためだけにダミーオブジェクトをインスタンス化する必要がないようにします。

過去に、DAL 呼び出しを含む作成ロジックを実際のコンストラクターに組み込みました (依存性注入を使用して、データ構成をオブジェクトに取得します)。この場合、コンストラクターはIdorのようなものを受け取りNameます -- オブジェクトを識別するために使用するもの。これを DAL に渡し、結果セットに基づいてオブジェクトを構築します。

于 2010-09-16T14:30:28.513 に答える
0

間違っている場合は訂正してください。ただし、部分的な Employee クラスを 2 つの異なる名前空間 (DAL と BLL) に作成することで、2 つの異なるクラスを作成するだけです。2 つの部分クラスで構成される単一のクラスを作成したいようです。この例ではそうではありません。コード例では、部分的な識別子を単純に削除できます。

それとは別に、ユーザー インターフェイスとデータ アクセスからビジネス ロジックを分離することは、私の意見では良い方法です。そのため、同じ Visual Studio プロジェクトで 3 つのアセンブリを使用するか、単純に 3 つのフォルダーを使用します。最終的には、ソリューションの複雑さに常に依存します。

特に LINQ to SQL またはエンティティを使用する場合は、データ アクセス レイヤーにできるだけ多くの LINQ コードを保持することをお勧めします。これにより、コードの再利用性とテスト性が向上します。

于 2010-09-16T14:35:25.413 に答える
0

これにより2つの別個のクラスが作成されることは、他の誰もが正しいです。2 つの別個のクラスを作成せず、部分クラスを介してロジックからデータを分離するには、プロジェクトに次の 2 つのファイルを含めることができます。

  • Employee.cs
  • Employee.bl.cs

次に、Employee.cs コードは次のようになります。

namespace YourNamespace
{
    partial class Employee
    {
        public string EmpID { get; set; }
        public string EmpName { get; set; }
    }
}

Employee.bl.cs は次のようになります。

namespace YourNamespace
{
    partial class Employee
    {
        public static List<Employee> GetListOfEmployees()
        {
            //DATA ACCESS
            var emps = GetEmployeesFromDb(); // fetch from db
            return emps;
        }
    }        
}

データを取得するためのクラスを持つことは、内部をRepository持つよりも適切だと思いますが。GetListOfEmployeesEmployee

アップデート：

リポジトリと言うときは、リポジトリ デザイン パターンを指しています。リポジトリは、(リレーショナル データベースなどから) オブジェクトを取得および格納するためのインターフェイスです。LINQ to SQL や ADO.NET Entity Framework などの ORM を使用している場合、通常、この役割を満たすクラスが自動生成されます。ただし、独自のデータベース アクセス コードを記述する場合は、次のように独自のリポジトリ クラスを作成できます。

public class Repository
{
    public Repository(string connectionString)
    {
        // ...
    }

    public IEnumerable<Employee> GetEmployees()
    {
        return GetEmployeesFromDb();
    }

    public Employee GetEmployeeById(Guid id)
    {
        // ...
    }

    public void StoreEmployee(Employee employee)
    {
        // ...
    }

    // etc.
}

Employeeこれの利点は、クラスまたは他の永続クラス全体にデータベース コードを配置する必要がないことです。データベースへのアクセスはすべて、1 つのインターフェイスを介して行われます。interfaceまた、リポジトリの複数の実装を作成して持つこともできます。Employeeそうすれば、たとえば、Employeeクラスを変更することなく、インスタンスをファイルに格納する方法が得られます。

于 2010-09-16T14:42:36.193 に答える
0

(1) ビジネス オブジェクト/テーブル エンティティを共有の特定の場所に配置します。次のクラスがあるとします: Employee (テーブル Employees の 1 行を参照する場合があります)、Department (テーブル Departments の 1 行を参照する場合があります) など。これらのクラスは、おそらくすべてのレイヤーで使用されます。そのため、適切な名前のフォルダーがある共有の場所にそれらを配置します。

(2) エンティティにビジネス ロジック/データ ロジックを配置しないでください。GetListOfEmployeesを入れているのがわかりますEmployee。しかし実際には、それらの間にはほとんど関係がありません。検索、更新、削除などの従業員に対するアクションがある EmployeeManager というクラスが必要です。

(3) GetListOfEmployeesBLL と DAL のメソッドを参照してください。まったく同じです。しかし、BLL のメソッドには「ビジネス ロジック」が含まれることになっているため、BL 層と呼んでいます。BLL では、メソッドの名前は「ビジネス ワード」と見なされます。たとえば、メソッドでは、DAL に「名前順にすべての従業員が必要です」と伝えます。BLL は「必要なもの」を伝え、DAL はピッキングを行います。DAL のメソッドにはビジネス的な要素はありません。

于 2010-09-16T14:46:07.790 に答える
0

OP をエスケープしている可能性があることの 1 つは、名前空間は、ある種の名前マングリングを実行する空想的な方法にすぎないということです。それは のコンパイルされた型に解決され、それは のコンパイルされた型に解決されると考えることができます。(これは実際に起こることではありませんが、私の説明の目的には合っています。)BLL.EmployeeBLL_EmployeeDAL.EmployeeDAL_Employee

ランタイムが型を比較す​​るとき、BLL_Employee != DAL_Employee. その結果、DAL.Employee を部分クラスとして宣言しても意味がありません。これDAL_Employeeは、実装の残りの部分を埋めて提供するものが他にないためです。

やりたいことは、同じ名前空間に 2 つのファイルを作成することです。

// Employee.cs (In a BLL folder)
namespace BLL
{
    public class Employee
    {
        // Custom business logic.
    }
}

// Employee.cs (In the DAL folder)
namespace DAL
{
    public class Employee
    {
        // Custom data access code here. 
        // Not overwritten by code generator
    }
}

// Employee.designer.cs (In the DAL folder)
namespace DAL
{
    public partial class Employee
    {
        // Generated code goes here.
        // Frequently updated by code generation tools.
        // Do not manually update this code.
    }
}

さらに、ビジネスロジックとデータ アクセスロジックを混在させたくありません。これは、BLL および DAL 名前空間のクラスをマージする目的のように思えます。メジャーノーノー。それらを別々に保管してください。DAL 名前空間のデータ アクセス クラスを非表示にし、BLL 名前空間から適切なビジネス オブジェクトを単に返す、呼び出すクラスの 3 番目のセットを導入することを検討してください。これにより、DAL 名前空間は BLL 名前空間を認識する必要がなくなり、BLL 名前空間は DAL 名前空間を認識する必要がなくなります。

于 2010-09-16T15:02:13.973 に答える