Các lớp lập trình .NET và POCO

Tôi đã có một suy nghĩ tối nay trong khi suy nghĩ về một số ứng dụng tôi cần thay đổi và nó làm tôi suy nghĩ. Các thực thể khung thực thể là POCO (Đối tượng CLR cũ) và các mô hình được sử dụng trong ASP.NET MVC thường cũng là POCO. Điều này về cơ bản có nghĩa là chỉ thuộc tính, không có phương pháp.

Bây giờ lập trình OO thường cho phép một đối tượng đóng gói chức năng của nó, bao gồm các thuộc tính cũng như các phương thức của nó, điều này cho phép xảy ra đa hình. Với sự gia tăng của các lớp POCO đang được sử dụng, các mẫu thiết kế như kho lưu trữ chung đã trở nên phổ biến hơn. Trước đây, các đối tượng của tôi đã có các hoạt động CRUD của riêng họ, bây giờ tôi có chúng trên một kho lưu trữ.

Đây có phải chỉ là một sự tiến hóa trong OO khi các hoạt động CRUD được loại bỏ khỏi các đối tượng để cho phép chúng được tách rời hoặc có thể các hoạt động CRUD không nên ở cấp đối tượng trong quá khứ và tôi đã sai? chết tiệt, có lẽ cả hai đều hoàn toàn hợp pháp và luôn luôn như vậy. Nó chỉ là một quan sát khiến tôi suy nghĩ, vì vậy tôi nghĩ rằng tôi sẽ tìm kiếm ý kiến ​​khác.

Như Wyatt đã nói, POCO và POJO không có nghĩa là không có phương pháp. Tôi nghĩ rằng bắt nguồn từ việc không biết POCO và không POJO là gì.

Các phiên bản đầu tiên của công nghệ ORM không phải là POCO và POJO đơn giản vì nó yêu cầu các thực thể kế thừa một số lớp cơ sở từ chính khung công tác. Trong trường hợp Java, Entity Beans. Trong trường hợp Entity Framework, POCO không thể có trong phiên bản đầu tiên và mỗi thực thể được yêu cầu kế thừa Entitylớp cơ sở.

Yêu cầu này tạo ra sự phụ thuộc của mô hình dữ liệu của bạn vào công nghệ kiên trì, điều này làm cho nhiều thứ trở nên khó khăn hoặc không thể. Những thứ như kiểm thử đơn vị mô hình đòi hỏi phải chế tạo khung bean / thực thể được chứng minh là thực tế không thể. Bạn cũng không thể sử dụng mô hình với công nghệ kiên trì khác nhau hoặc bạn không thể sử dụng mô hình trong các ngữ cảnh khác nhau, như trong môi trường di động.

Vì vậy, giả định của bạn rằng POCO là về sự không tồn tại của các phương thức là sai. POCO là về việc có thể sử dụng mô hình tách biệt với công nghệ bền bỉ của nó.

Những gì bạn đang nói có lẽ là đóng cho Mô hình miền thiếu máu so với mô hình miền thích hợp.

POCO hoàn toàn không có nghĩa là không có phương thức - mặc dù hầu hết các ví dụ mà người ta thấy sử dụng nhiều tính năng ràng buộc tự động của MVC chủ yếu liên quan đến các thuộc tính và bỏ qua các phương thức.

Có sự kiên trì được nhúng trong các đối tượng mô hình của bạn vi phạm sự phân tách các mối quan tâm và làm cho việc thực hiện những việc như đơn vị kiểm tra các đối tượng mà không cần cơ sở dữ liệu là rất khó. Nó không phải là một chức năng của đối tượng mô hình mà là một chức năng nếu một lớp khác như kho lưu trữ.

Chỉ cần hai cách tiếp cận khác nhau với giá trị riêng của họ.

/programming/1519669/data-access-layer-or-having-object-with-crud-methods

Gần đây tôi đã sử dụng các Phương thức mở rộng cho những thứ như thế này.

POCO chứa logic chỉ có ý nghĩa đối với chính đối tượng. Logic nghiệp vụ hoặc logic đối tượng phối hợp đi vào một phần mở rộng BL. Truy cập dữ liệu có thể đi vào lớp truy cập dữ liệu hoặc phần mở rộng truy cập dữ liệu.

namespace MyApp
{
    public class MyClass
    {
        public string id;
        public string name;
        public int quantity;
        public decimal price;
    }   
}

namespace MyAppBL
{
    public static class MyClassBL
    {
        public static decimal PriceInCart(this MyClass myObject)
        {
            return myObject.quantity > 10 ? myObject.price * 0.9m : myObject.price;
        }
    }
}

namespace MyAppDA
{
    public static class MyClassDA
    {
        public static void Create()
        {
            …
        }

        public static void Read(string myObject)
        {
            …
        }

        public static void Update(this MyClass myObject)
        {
            …
        }

        public static void Delete(this MyClass myObject)
        {
            …
        }
    }
}

Điều này cung cấp cho bạn rất tốt myObject.PriceInCart()và myObject.Save()trong khi giữ cho lớp của bạn tập trung vào dữ liệu. Tất nhiên đối với các phương thức tĩnh bạn cần phải có MyAppDA.Create()thay vì MyApp.Create().