2009-11-23 27 views
6

Vì vậy, tôi đang làm việc để tạo bản nháp cho chương trình của mình.Logic kinh doanh của tôi nên tương tác với lớp dữ liệu của tôi như thế nào?

Đây là kế hoạch của tôi:

GUI 
--- 
Business Logic 
--- 
Data 

Bạn sẽ có thể thay thế một trong hai GUI hoặc lớp Data không có vấn đề. Mỗi lớp tự xem. Vì vậy, GUI sẽ gọi phương thức từ Business logic và các phương thức sẽ luôn trả về trạng thái và có lẽ một số dữ liệu. Làm thế nào GUI nên đáp ứng với dữ liệu, nên luôn luôn được quyết định trong lớp GUI. Logic kinh doanh không có ảnh hưởng gì đến điều này. Vì vậy, các mối quan hệ với GUI và logic nghiệp vụ đã được giải quyết. Tôi hy vọng bạn có thể theo tôi.

Bây giờ, hãy tìm một thứ cụ thể hơn. Kế hoạch của tôi cho lớp dữ liệu, là sử dụng cơ sở dữ liệu. Bây giờ, Business Logic nên gọi phương thức từ lớp dữ liệu như thế nào?

Có lẽ tôi nên tạo một enum, tương ứng với các truy vấn SQL được mã hóa khác nhau, mà lớp dữ liệu nhận thức được?

Ví dụ:

Datalayer.GetResults(Queries.GetAllCustomersIDs); 

Truy vấn là một sự kiện.

Nếu đây là cách phù hợp, GetResults sẽ trở lại như thế nào? một mảng chuỗi? nhưng nếu truy vấn có dữ liệu đa chiều thì sao?

Tôi có nên sử dụng 2 phương pháp chung chung không?

Datalayer.GetSingleDimensionResults(SingleDimensionQueries.GetAllCustomersIDs); 
Datalayer.GetMultipleDimensionResults(MultiDimensionQueries.GetAllCustomers); 

Hoặc tôi có lẽ nên có truy vấn cho từng loại yêu cầu dữ liệu?

Datalayer.GetAllCustomerIDs; 
DataLayer.GetAllCustomers; 

, vv

Trả lời

7

Nói chung, những gì tôi sử dụng để làm là: lớp

dữ liệu:

Để truy cập dữ liệu, tôi tạo ra một giao diện, cho từng đối tượng. Mỗi giao diện liệt kê tất cả các phương thức truy cập dữ liệu công khai cho đối tượng được đề cập. Để giữ dữ liệu, tôi cũng tạo các loại vùng chứa cho từng đối tượng, có thể là cấu trúc hoặc các lớp đơn giản chỉ với dữ liệu. Tôi cũng dựa vào bộ dữ liệu ngôn ngữ, như danh sách, để giữ dữ liệu của tôi, vì vậy tôi không liên kết với một loại cơ sở dữ liệu cụ thể. Sau đó, tôi tạo một lớp thực hiện các giao diện dữ liệu, lớp này có tất cả SQL và truy cập cơ sở dữ liệu, vì vậy trong trường hợp thay đổi công nghệ lưu trữ dữ liệu, đây là lớp duy nhất sẽ được thay đổi.

lớp kinh doanh:

Có tất cả các logic với dữ liệu, làm thế nào để xác nhận, phương pháp Mà từ các giao diện dữ liệu nên được gọi và thứ tự.Lớp này nhận và gửi "" dữ liệu đến lưu trữ dữ liệu hoặc GUI, sử dụng các thùng chứa (danh sách ví dụ), nơi các kiểu dữ liệu là các thùng chứa của tôi được đề cập ở trên.

GUI:

Gọi phương thức logic nghiệp vụ và hiển thị/trình bày dữ liệu định dạng. Không có logic ở đây ngoài việc gọi đúng phương pháp của logic nghiệp vụ.

mã nhỏ ví dụ về một container (C#)

//Interface for Department class data access. DataStorage assembly 

    namespace DataStorage 
    { 
     public interface IDepartmentDS 
     { 
      void Open(); //Open data conection 
      void Close(); //Close data conection 
      List<Repositories.Department> List(); //Gets all departments (from data base) 
     } 
    } 


    //This class holds all data regarded a department. There's no logic here. Repositories assembly 

    namespace Repositories 
    { 
     public class Department 
     { 
      [Browsable(false)] 
      public Department() 
      { 
      } 

      [Browsable(false)] 
      public Department(String Symbol, String Name) 
      { 
       this.Symbol = Symbol; 
       this.DeptName = Name; 
      } 

      public Department(Department department) 
      { 
       this.Symbol = department.Symbol; 
       this.DeptName = department.DeptName; 
      } 

      [Browsable(false)] 
      public String Symbol { get; set; } 

      public String DeptName { get; set; } 
     } 
    } 


    //This class implements the data manipulation itself, accessing the real database. 
    //However the data exchange outside this class is done via repositories classes and 
    //Generics - Lists mainly 

    public class DataStorage : IDepartmentDS 
    { 
     //Here I use to put generic functions to connect with the database, format stored 
     //procedure parameters list etc. 

     //Implementation of the List method declare in the Department Interface 
      List<Repositories.Department> IDepartmentDS.List() 
      { 
       String query = String.Format("SELECT * FROM {0}", DepartmentTable); 
       int rows = 0; 
       DataSet ds = ExecSqlCommand(query, out rows); //this method is private to this class 

       if (ds == null) 
        return null; 

       List<Repositories.Department> list = new List<Repositories.Department>(); 
       foreach (DataRow row in ds.Tables[0].Rows) 
       { 
        list.Add(new Repositories.Department((String)row[DepFN_Symbol], (String)row[DepFN_DepName])); 
        //DepFN_Symbol and the others are just const variables representing the column index 
       } 

       return list; 
      } 

    } 

public class DepartmentLogic 
{ 
    public DepartmentLogic() 
    { 
     ..... 
    } 

    public List<Repositories.Department> GetAllDepartments() 
    { 
     //Here I create an Instance of the DataStorage but using the Department interface 
     //so I restrict the access to Department data methods only. It could be a good 
     //idea here to use the factory pattern. 

     IDepartmentDS department = (IDepartmentDS) new DataStorage(); 
     department.Open(); 

     List<Repositories.Department> departments = department.List(); 

     department.Close(); 

     return departments; 
    } 

} 

dụ Kinh doanh logic này, quả thật vậy, rất đơn giản, chỉ cần cho thấy làm thế nào để lấy dữ liệu từ lớp lưu trữ, nhưng miễn là bạn có quyền truy cập vào dữ liệu , bạn có thể thao tác nó theo cách bạn muốn. Chỉ cần một bình luận ở đây: có lẽ giải pháp này nên được tái suy nghĩ nếu được thực hiện trong một máy chủ rất bận rộn với hàng ngàn yêu cầu bởi vì nó có thể sử dụng rất nhiều bộ nhớ.

Đối với logic nghiệp vụ và cũng là điểm giao diện người dùng, tất cả dữ liệu được truyền thông giữa các mô-đun bằng cách sử dụng các mục đích chung như Danh sách. Điểm liên kết giữa tất cả các mô-đun đó là các lớp chứa để tất cả các lớp được tách ra ít hơn.

Giao diện người dùng thực hiện các yêu cầu đối với các lớp logic nghiệp vụ, vì vậy nó hoạt động như một nhà cung cấp dịch vụ. Làm theo cách đó, việc thay đổi giao diện người dùng sẽ không ảnh hưởng đến các lớp bên dưới.

Yêu cầu logic nghiệp vụ và gửi dữ liệu đến các lớp lưu trữ dữ liệu bằng cách sử dụng dữ liệu mục đích chung, vì vậy việc thay đổi công nghệ lưu trữ/lưu trữ dữ liệu sẽ không ảnh hưởng đến nó.

Đó là cách tôi sử dụng để làm và tôi đang cố gắng cải thiện nó;)

+0

Bạn có thể đưa ra ví dụ trong đó logic nghiệp vụ truy lục một số dữ liệu từ lớp dữ liệu không? – CasperT

+0

Tôi hiểu ý bạn là gì bởi các vùng chứa và cứ thế. Nhưng tôi vẫn không chắc làm thế nào nó sẽ lấy dữ liệu - cách nào là tốt nhất. – CasperT

+0

Tôi nghĩ rằng tôi đang bị ném ra bởi điều này: "Mỗi giao diện liệt kê tất cả các phương pháp truy cập dữ liệu công khai cho đối tượng trong câu hỏi." Tôi thực sự sẽ đánh giá cao một số ví dụ nhỏ – CasperT

2

dữ liệu của bạn "Layer" có lẽ nên được nhiều hơn một tập hợp các truy vấn ngữ nghĩa và bạn nên rút gọn trong một API, nếu không lớp Business Logic của bạn sẽ phải biết quá nhiều về triển khai lớp dữ liệu của bạn. Cùng một lý do bạn đã sử dụng giữa các lớp GUI và Business Logic của bạn nên áp dụng và cho cùng một mục đích.

+0

bạn có thể hiển thị ví dụ về điều này không? – CasperT

Các vấn đề liên quan