Programowanie .NET i klasy POCO

Myślałem dziś wieczorem, zastanawiając się nad aplikacją, którą muszę zmienić i przyszło mi to do głowy. Entity Framework Entities to POCO (Plain old CLR Objects), a modele używane w ASP.NET MVC są zwykle również POCO. Zasadniczo oznacza to tylko właściwości, bez metod.

Teraz programowanie OO normalnie pozwala obiektowi obudować jego funkcjonalność, która obejmuje zarówno jego właściwości, jak i metody, co pozwala na wystąpienie polimorfizmu. Wraz ze wzrostem liczby klas POCO, wzorce projektowe, takie jak repozytoria ogólne, stały się bardziej popularne. Kiedy w przeszłości moje obiekty miały własne operacje CRUD, teraz mam je w repozytorium.

Czy to tylko ewolucja w OO, w której operacje CRUD są usuwane z obiektów, aby umożliwić ich oddzielenie, czy może operacje CRUD nie powinny być w przeszłości na poziomie obiektu, a ja się myliłem? cholera, może oba są całkowicie uzasadnione i zawsze były. To tylko spostrzeżenie, które skłoniło mnie do myślenia, więc pomyślałem, że będę szukał innych opinii.

Jak powiedział Wyatt, POCO i POJO w żaden sposób nie sugerują żadnych metod. Myślę, że wynika to z tego, że nie wiemy, czym jest non-POCO i non-POJO.

Pierwsze wersje technologii ORM nie były POCO i POJO tylko dlatego, że wymagały od jednostek dziedziczenia klasy bazowej z samego frameworka. W przypadku Javy Entity Beans. W przypadku Entity Framework POCO nie było możliwe w pierwszej wersji i każda jednostka musiała odziedziczyć Entityklasę podstawową.

To wymaganie stworzyło zależność twojego modelu danych od technologii trwałości, co sprawia, że ​​wiele rzeczy jest trudnych lub niemożliwych. Rzeczy takie jak testowanie jednostek wymaga wyśmiewania frameworka bean / bytu, co okazało się praktycznie niemożliwe. Nie można również używać modelu z inną technologią trwałości lub nie można używać modelu w innym kontekście, na przykład w środowisku mobilnym.

Zatem twoje założenie, że POCO dotyczy braku metod, jest błędne. POCO polega na możliwości wykorzystania modelu w oderwaniu od technologii trwałości.

To, o czym mówisz, jest prawdopodobnie zbliżone do modelu domeny anemicznej vs. właściwego modelu domeny.

POCO w żaden sposób nie sugeruje, że nie ma metod - chociaż większość przykładów, które widzimy, wykorzystuje wiele funkcji automatycznego wiązania MVC, które dotyczą głównie właściwości i ignorują metody.

Posiadanie trwałości osadzonej w obiektach modelu narusza separację problemów i bardzo utrudnia wykonywanie takich rzeczy, jak testowanie jednostkowe obiektów bez stawiania bazy danych. Nie jest to funkcja obiektu modelu, ale funkcja innej klasy, takiej jak repozytorium.

Tylko dwa różne podejścia, z których każdy ma swoje zalety.

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

Ostatnio używam metod rozszerzeń do takich rzeczy.

POCO zawiera logikę, która ma sens tylko dla samego obiektu. Logika biznesowa lub skoordynowana logika obiektowa wchodzi w rozszerzenie BL. Dostęp do danych może przejść do warstwy dostępu do danych lub rozszerzenia dostępu do danych.

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)
        {
            …
        }
    }
}

To daje bardzo miły myObject.PriceInCart()i myObject.Save()jednocześnie skupiając klasę na danych. Oczywiście w przypadku metod statycznych musisz MyAppDA.Create()zamiast tego MyApp.Create().