.NET Programlama ve POCO sınıfları

Bu gece değiştirmem gereken bazı uygulamalar üzerinde düşünürken bir düşünmeye başladım ve beni düşündürdü. Varlık Çerçevesi Varlıklar POCO'dur (Düz eski CLR Nesneleri) ve ASP.NET MVC'de kullanılan modeller de genellikle POCO'dur. Bu temelde sadece özellikler anlamına gelir, yöntem yok.

Şimdi OO programlama normal olarak bir nesnenin özelliklerini ve yöntemlerini içeren işlevselliğini kapsüllemesine izin verir, bu polimorfizmin gerçekleşmesine izin verir. POCO sınıflarının yükselişi ile jenerik depolar gibi tasarım modelleri daha popüler hale geldi. Geçmişte nesnelerimin kendi CRUD operasyonları olduğunda, şimdi onları bir depoda bulunduruyorum.

Bu sadece OO'da, CRUD işlemlerinin ayrıştırılmasına izin vermek için nesnelerden çıkarıldığı bir evrim mi, yoksa CRUD operasyonları geçmişte nesne düzeyinde olmamalı ve ben de yanlış mıydım? heck, belki de her ikisi de mükemmel yasal ve her zaman olmuştur. Bu sadece beni düşündüren bir gözlem, bu yüzden başka görüşler arayacağımı düşündüm.

Wyatt'ın dediği gibi, POCO ve POJO hiçbir şekilde hiçbir yöntem ifade etmez. Bence bu POCO olmayan ve POJO olmayan ne bilmiyorum kaynaklanıyor.

ORM teknolojilerinin ilk sürümleri POCO ve POJO değildi, çünkü bu, varlıkların bazı temel sınıfları çerçevenin kendisinden miras almasını gerektiriyordu. Java durumunda Entity Beans. Entity Framework için POCO ilk sürümde mümkün değildi ve her varlığın Entitytemel sınıfı devralması gerekiyordu .

Bu gereksinim, veri modelinizin kalıcılık teknolojisine bağımlılığını yarattı, bu da birçok şeyi zor veya imkansız kılıyor. Modeli test etmek gibi şeyler, neredeyse imkansız olduğu kanıtlanan fasulye / varlık çerçevesine alay etmeyi gerektirir. Modeli farklı kalıcılık teknolojisiyle kullanamazsınız veya mobil ortamda olduğu gibi farklı bağlamlarda kullanamazsınız.

POCO'nun yöntemlerin yokluğu ile ilgili olduğu varsayımınız yanlıştır. POCO, modeli kalıcılık teknolojisinden ayrı olarak kullanabilmekle ilgilidir.

Bahsettiğiniz şey muhtemelen Anemic Domain Model'e karşı uygun domain modeline yakın.

POCO hiçbir şekilde yöntem olmadığını ima etmez - örneklerin çoğunda esas olarak özelliklerle ilgilenen ve yöntemleri görmezden gelen MVC otomatik bağlama özelliklerinin çoğunun kullanıldığı görülür.

Model nesnelerinizde kalıcılığa sahip olmak, endişelerin ayrılmasını ihlal eder ve bir veritabanına dayanmadan nesneleri test etmek gibi nesneleri test etmeyi çok zorlaştırır. Model nesnesinin bir işlevi değil, havuz gibi farklı bir sınıfın işlevi.

Her biri kendi değerlerine sahip iki farklı yaklaşım.

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

Son zamanlarda böyle şeyler için Uzantı Yöntemleri kullanıyorum .

POCO, sadece nesnenin kendisi için anlamlı olan bir mantık içerir. İş mantığı veya koordineli nesne mantığı bir BL uzantısına gider. Veri erişimi bir veri erişim katmanına veya bir veri erişim uzantısına gidebilir.

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

Bu size çok hoş myObject.PriceInCart()ve myObject.Save()sınıfınızı verilere odaklanmış tutarken verir. Tabii MyAppDA.Create()bunun yerine statik yöntemlere ihtiyacınız var MyApp.Create().