.NET програмування та класи POCO

Я думав сьогодні ввечері, розмірковуючи над якоюсь програмою, яку мені потрібно змінити, і це змусило мене задуматися. Елементами Entity Framework є POCO (Plain Old CLR Objects), а моделі, що використовуються в ASP.NET MVC, зазвичай також є POCO. Це в основному означає просто властивості, ніяких методів.

Тепер програмування OO зазвичай дозволяє об'єкту інкапсулювати свою функціональність, що включає його властивості, а також його методи, це дозволяє поліморфізму. З підйомом класів POCO, що використовуються, моделі дизайну, такі як загальні сховища, стають все більш популярними. Коли раніше мої об’єкти мали б власні CRUD-операції, тепер я маю їх у сховищі.

Це просто еволюція в ОО, коли операції CRUD видаляються з об'єктів, щоб вони могли бути відокремленими, або, можливо, операції CRUD не повинні були бути на рівні об'єктів у минулому, і я помилявся? чорт, може, обидва цілком законно і завжди були. Це лише спостереження, яке змусило мене задуматися, тому я подумав, що я буду шукати інших думок.

Як сказав Віатт, POCO та POJO жодним чином не передбачають ніяких методів. Я думаю, що це випливає з невідомого, що таке не-POCO та non-POJO.

Перші версії ORM-технологій не були POCO та POJO просто тому, що це вимагало від об'єктів успадкувати деякий базовий клас із самого фреймворку. У випадку Java, Entity Beans. У випадку Entity Framework, POCO не був можливим у першій версії, і кожному об'єкту потрібно було успадкувати Entityбазовий клас.

Ця вимога створила залежність вашої моделі даних від технології збереження, яка робить багато речей важкими або неможливими. Такі речі, як тестування одиничної моделі, вимагають знущання над структурою боб / сутність, що виявилося практично неможливим. Ви також не можете використовувати модель з різною технологією збереження або не можете використовувати модель в іншому контексті, як у мобільному середовищі.

Отже, ваше припущення, що POCO стосується неіснуючих методів, є помилковим. POCO - це можливість використовувати модель у відриві від своєї технології збереження.

Те, про що ви говорите, ймовірно, закривається для Anemic Domain Model vs належної доменної моделі.

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().