.NET программирование и классы POCO

Сегодня вечером я думал о каком-то приложении, которое мне нужно изменить, и это заставило меня задуматься. Entity Framework Entity - это POCO (простые старые объекты CLR), а модели, используемые в ASP.NET MVC, обычно также POCO. Это в основном означает только свойства, а не методы.

Теперь ОО-программирование обычно позволяет объекту инкапсулировать свою функциональность, которая включает его свойства, а также методы, что позволяет полиморфизму происходить. С ростом использования классов POCO шаблоны проектирования, такие как универсальные репозитории, стали более популярными. Когда в прошлом у моих объектов были свои собственные операции CRUD, теперь у меня они есть в хранилище.

Является ли это просто эволюцией в ОО, когда операции CRUD удалены из объектов, чтобы их можно было разъединить, или, может быть, операции CRUD не должны были быть на уровне объектов в прошлом, и я ошибался? черт возьми, возможно, оба совершенно законны и всегда были. Это просто наблюдение, которое заставило меня задуматься, так что подумал, что я буду искать другие мнения.

Как сказал Уайетт, POCO и POJO никоим образом не подразумевают никаких методов. Я думаю, что это происходит из-за незнания того, что такое не POCO и не POJO.

Первые версии технологий ORM не были POCO и POJO просто потому, что требовалось, чтобы объекты наследовали некоторый базовый класс от самой платформы. В случае Java, Entity Beans. В случае Entity Framework POCO не было возможно в самой первой версии, и каждая сущность должна была наследовать Entityбазовый класс.

Это требование создало зависимость вашей модели данных от технологии персистентности, что делает многие вещи трудными или невозможными. Такие вещи, как модульное тестирование модели, требуют проверки структуры bean / entity, что оказалось практически невозможным. Вы также не можете использовать модель с другой технологией персистентности или не можете использовать модель в другом контексте, как в мобильной среде.

Таким образом, ваше предположение, что POCO касается несуществования методов, неверно. POCO - это возможность использовать модель в отрыве от технологии постоянства.

То, о чем вы говорите, вероятно, близка к модели Anemic Domain Model против правильной модели домена.

POCO никоим образом не подразумевает, что нет методов - хотя большинство примеров, которые мы видим, используют большую часть функций автоматического связывания MVC, которые в основном имеют дело со свойствами и игнорируют методы.

Наличие постоянства в ваших объектах модели нарушает разделение интересов и делает очень трудным выполнение таких вещей, как модульное тестирование объектов без поддержки базы данных. Это не функция объекта модели, а функция другого класса, такого как хранилище.

Просто два разных подхода, каждый со своими достоинствами.

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

В последнее время я использую методы расширения для подобных вещей.

POCO содержит логику, которая имеет смысл только для самого объекта. Бизнес-логика или логика согласованного объекта входит в расширение BL. Доступ к данным может идти либо на уровень доступа к данным, либо на расширение доступа к данным.

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

Это дает вам очень хороший myObject.PriceInCart()и myObject.Save()при этом держать ваш класс сосредоточен на данных. Конечно, для статических методов вам нужно иметь MyAppDA.Create()вместо MyApp.Create().