Bạn phân loại loại thiết kế này cho các lớp như thế nào?

Question

Loại thiết kế sau đây mà tôi đã thấy về cơ bản có các lớp "mỏng", loại trừ bất kỳ loại hành vi nào. Một lớp phụ được sử dụng để chèn/cập nhật/xóa/nhận.

Điều này có sai không? Nó có chống OOP không?

User.cs 

public class User 
{ 

    public string Username { get; set; } 
    public string Password { get; set; } 
} 


Users.cs 


public class Users 
{ 
    public static User LoadUser(int userID) 
    { 
      DBProvider db = new DBProvider(); 
      return dp.LoadUser(userID); 

     } 

} 

Answer 1

Tôi sẽ phân loại nó làm đối tượng miền hoặc đối tượng kinh doanh. Một lợi ích của kiểu thiết kế này là nó giữ mô hình bất khả tri của bất kỳ logic nghiệp vụ nào và chúng có thể được tái sử dụng trong các loại môi trường khác nhau.

Lớp thứ hai có thể được phân loại là DAO (Đối tượng truy cập dữ liệu).

Mẫu này không chống oop và được sử dụng rộng rãi.

Answer 2

Tôi nghĩ bạn đang triển khai domain model và data-access object. Đó là một ý tưởng hay.

Answer 3

Trong khi lớp user.cs của bạn tự cho vay theo hướng domain transfer object, lớp Users.cs về cơ bản là nơi bạn có thể áp dụng quy tắc kinh doanh trong số data-access objects.

Bạn có thể muốn suy nghĩ về quy ước đặt tên của các lớp học cùng với các không gian tên. Khi tôi nhìn vào users.cs, tôi giả định rằng về cơ bản nó sẽ là một lớp để làm việc với một danh sách người dùng.

Một tùy chọn khác sẽ là xem xét Active Record Pattern, kết hợp hai lớp mà bạn đã tạo.

User.cs 

public class User 
{ 
    public string Username { get; set; } 
    public string Password { get; set; } 

    public User(int userID) 
    { 
     //data connection 
     //get records 
     this.Username = datarecord["username"]; 
     this.Password = datarecord["password"]; 
    } 
} 

Answer 4

Có vẻ như nó có thể là repository pattern này có vẻ là một mô hình ngày càng phổ biến và được sử dụng để lớn ảnh hưởng trong Rob Conery's Storefront dụ ứng dụng Asp.Net MVC.

Về cơ bản, bạn đang trừu tượng hóa mã truy cập dữ liệu của mình khỏi Mô hình, một điều hay, nói chung. Mặc dù tôi sẽ hy vọng cho một chút can đảm cho lớp mô hình. Cũng từ kinh nghiệm trước đó, gọi nó là người dùng khó hiểu, UserRepository có thể là beter. Cũng có thể muốn xem xét loại bỏ tĩnh (đó là một cuộc tranh luận nóng) nhưng làm cho mocking dễ dàng hơn. Cộng với kho lưu trữ nên được thực hiện một giao diện để bạn có thể thử nó và do đó thay thế nó bằng một giả sau này.

Answer 5

Nó không thực sự hướng đối tượng theo bất kỳ ý nghĩa nào, vì đối tượng không là gì ngoài một nhóm dữ liệu gắn bó với nhau. Không phải đó là một điều khủng khiếp.

Answer 6

Lớp đầu tiên là chống OOP vì lớp này chứa dữ liệu không có hành vi, ví dụ điển hình của anemic domain model. Nó là điển hình cho những người lập trình thủ tục trong một ngôn ngữ OO. Tuy nhiên, ý kiến ​​được đặt ra cho dù nó có ý nghĩa hay không, hãy đặt logic truy cập DB vào chính mô hình miền (mẫu bản ghi hoạt động) hoặc, như trong mã của bạn, vào một lớp riêng biệt (Mẫu truy cập dữ liệu), kể từ khi truy cập DB là một mối quan tâm kỹ thuật riêng biệt không nhất thiết phải được kết hợp chặt chẽ với mô hình miền.