GUI, BLL, DAL Tổ chức trong một dự án

Tôi đang đọc về các lớp ứng dụng và muốn sử dụng thiết kế này trong dự án tiếp theo của tôi (c #, .Net). Vài câu hỏi:

1. Là sự phân tách các lớp được thực hiện thông qua các không gian tên? Project.BLL.Whthing, Project.DAL.Whthing

2. Có thích hợp hơn để phân tách theo các lớp, sau đó các thành phần (Project.BLL.Component1) hoặc theo các thành phần, sau đó các lớp (Project.Component1.BLL)

3. Đối với DAL của tôi, lớp này có được tổ chức thêm bằng các lớp khác nhau không? Nếu tất cả các cuộc gọi cơ sở dữ liệu được đưa vào một lớp duy nhất, không có tổ chức. Sẽ tốt hơn nếu chia chúng ra với các lớp hoặc không gian tên khác nhau?

4. Các lớp DAL thường tĩnh? Có vẻ rườm rà khi khởi tạo một đối tượng DAL trước khi gọi một trong các phương thức của nó mỗi lần.

Bất kỳ lời khuyên nào khác để thực hiện mọi thứ theo cách chính xác với các lớp này sẽ được đánh giá cao.

1. Đúng. Và cũng lắp ráp.
2. Tôi tách từng lớp, rồi các thành phần.
3. Đúng. Có nhiều cách tiếp cận khác nhau, nhưng tôi có IDatabaseService (trừu tượng hóa các cách thức khác nhau trong đó cơ sở dữ liệu được gọi - đây gần như có thể là ánh xạ trực tiếp của ExecuteScalar / ExecuteNonQuery / ExecuteReader), và sau đó các lớp truy cập dữ liệu khác nhau phân vùng theo loại dữ liệu. Ví dụ: bạn có thể có một lớp UserDataAccess sẽ có các phương thức CRUD đơn giản để tạo / sửa đổi / xóa các đối tượng Người dùng. Một cách tiếp cận khác là có một đối tượng Người dùng có CRUD được tích hợp ngay.

4. Không. Điều đó làm cho bài kiểm tra đơn vị khó hơn nhiều . Bạn nên sử dụng phép nội xạ phụ thuộc để truyền phụ thuộc vào hàm tạo của từng lớp truy cập dữ liệu (chẳng hạn như IDatabaseService). Sau đó, bạn sẽ chuyển các đối tượng truy cập dữ liệu vào các đối tượng kinh doanh, như thế này:

   BusinessObject businessObject = new BusinessObject (new DataAccessObject (new DatabaseService ())); businessObject.PerformOperation ();

Mỗi đối tượng kinh doanh có thể cần nhiều đối tượng truy cập dữ liệu. Mã GUI của bạn cũng sẽ sử dụng một hoặc nhiều đối tượng kinh doanh. Một số đối tượng kinh doanh có thể không cần bất kỳ đối tượng truy cập dữ liệu nào nhưng không bao giờ nên sử dụng IDatabaseService trực tiếp.

Đối với câu hỏi 1 và 2 đi với câu trả lời của Matthew.

Tôi đã dành rất nhiều thời gian để cố gắng tìm ra cách tốt nhất để cấu trúc DAL của các ứng dụng máy tính để bàn. Và cách tốt nhất thực sự phụ thuộc vào nhu cầu của ứng dụng. Trong một trong những ứng dụng của mình, tôi đã có một lớp DA cho mỗi bảng cơ sở dữ liệu, nó đã đăng ký chính nó với một lớp DataProvider trung tâm (ví dụ như singleton) và xử lý CRUD. Mỗi lớp DA sau đó có thể quyết định liệu nó có muốn lưu trữ tất cả dữ liệu bảng trong RAM hay không (hiệu suất!) Và / hoặc liệu nó có cần kích hoạt cập nhật máy khách tự động trong các máy khách khác chạy trên các máy tính khác hay không đồng thời). Điều này giúp dễ dàng thêm các lớp DAL mới, vì tất cả những gì họ phải làm là tuân thủ giao diện đăng ký.

Không phải mọi DAL đều cần loại chức năng này, nhưng tôi đã học được rằng chính cách tiếp cận (tức là nhà cung cấp dữ liệu đơn lẻ và các lớp DAL đơn giản với đăng ký tĩnh) giúp cuộc sống của tôi dễ dàng hơn rất nhiều khi tôi bắt đầu thêm các lớp mới.

Tôi chắc chắn sẽ không khuyên bạn nên xây dựng CRUD thành các lớp cấp cao hơn, trừ khi đây là một ứng dụng rất đơn giản. DAL là một sự trừu tượng của việc lưu trữ dữ liệu. Nếu bạn quyết định thay đổi lưu trữ dữ liệu của mình tại một thời điểm nào đó trong tương lai (ngay cả khi chỉ sử dụng MySQL thay vì MS SQL), bạn sẽ rất biết ơn vì điều đó. Plus: Các đối tượng BLL nên được cấu trúc bởi các mối quan hệ logic kinh doanh của chúng. Các đối tượng DAL được cấu trúc bởi các loại container lưu trữ mà chúng đại diện. Sự khác biệt có thể là kịch tính.

Đừng KHÔNG làm cho lớp DAL tĩnh của bạn. Những gì bạn đạt được về tốc độ mã hóa, bạn sẽ mất nhiều lần so với khả năng kiểm tra và tính linh hoạt.