Pemrograman .NET dan kelas POCO


9

Saya sedang berpikir malam ini sambil merenungkan beberapa aplikasi yang perlu saya ubah dan itu membuat saya berpikir. Entity Framework Entities adalah POCO (Plain old CLR Objects) dan model yang digunakan dalam ASP.NET MVC biasanya juga POCO. Ini pada dasarnya berarti hanya properti, tidak ada metode.

Sekarang pemrograman OO biasanya memungkinkan suatu objek untuk merangkum fungsinya, yang mencakup sifat-sifatnya serta metodenya, ini memungkinkan terjadinya polimorfisme. Dengan naiknya kelas POCO yang digunakan, pola desain seperti repositori generik menjadi lebih populer. Ketika di masa lalu objek saya akan memiliki operasi CRUD mereka sendiri, saya sekarang memilikinya di repositori.

Apakah ini hanya sebuah evolusi dalam OO di mana operasi CRUD dihapus dari objek untuk memungkinkan mereka untuk dipisahkan atau mungkin operasi CRUD seharusnya tidak pada level objek di masa lalu dan saya salah? heck, mungkin keduanya benar-benar sah dan selalu. Itu hanya pengamatan yang membuatku berpikir, jadi kupikir aku akan mencari pendapat lain.

Jawaban:


9

Seperti yang dikatakan Wyatt, POCO dan POJO sama sekali tidak mengandung metode. Saya pikir itu bermula dari tidak mengetahui apa itu non-POCO dan non-POJO.

Versi pertama teknologi ORM bukan POCO dan POJO hanya karena diperlukan entitas untuk mewarisi beberapa kelas dasar dari kerangka itu sendiri. Dalam kasus Java, Entity Beans. Dalam kasus Entity Framework, POCO tidak mungkin dalam versi pertama dan setiap entitas diharuskan untuk mewarisi Entitykelas dasar.

Persyaratan ini menciptakan ketergantungan model data Anda pada teknologi persistensi, yang membuat banyak hal menjadi sulit atau tidak mungkin. Hal-hal seperti pengujian unit model memerlukan mengejek kerangka kacang / entitas yang terbukti hampir mustahil. Anda juga tidak dapat menggunakan model dengan teknologi ketekunan yang berbeda atau Anda tidak dapat menggunakan model dalam konteks yang berbeda, seperti di lingkungan seluler.

Jadi anggapan Anda bahwa POCO adalah tentang tidak adanya metode adalah salah. POCO adalah tentang dapat menggunakan model dalam pemisahan dari teknologi ketekunannya.

Apa yang Anda bicarakan mungkin mendekati Model Domain Anemik vs model domain yang tepat.


Anda benar, itu memang lebih terlihat seperti Model Domain Anemik setelah membaca artikel itu.
James

4

POCO sama sekali tidak menyiratkan tidak ada metode - meskipun sebagian besar contoh yang dilihatnya menggunakan banyak fitur pengikatan otomatis MVC yang terutama berkaitan dengan properti dan mengabaikan metode.

Memiliki kegigihan yang tertanam dalam objek model Anda melanggar pemisahan kekhawatiran dan membuatnya sangat sulit untuk melakukan hal-hal seperti unit menguji objek tanpa berdiri di database. Ini bukan fungsi dari objek model tetapi fungsi jika kelas yang berbeda seperti repositori.


Eh? poco benar-benar menyiratkan tidak ada metode dalam pengalaman saya - selain itu entitas atau model atau model tampilan tergantung pada penggunaan.
Telastyn

2
Terakhir kali saya memeriksa sebuah objek C-Sharp Plain Tua bisa memiliki metode. Istilah ini muncul di masa lalu yang buruk di mana Anda memiliki hal-hal seperti set data yang diketik atau sebaliknya harus memiliki objek model Anda mewarisi dari kelas tertentu dan tidak menjadi POCO.
Wyatt Barnett

Pemisahan keprihatinan dapat dicapai sambil menjaga metode pada objek, dengan meminta metode menerima antarmuka. Antarmuka itu akan menentukan jenis yang dapat menangani operasi CRUD untuk objek.
James


0

Saya telah menggunakan Metode Ekstensi untuk hal-hal seperti ini akhir-akhir ini.

POCO berisi logika yang hanya masuk akal untuk objek itu sendiri. Logika bisnis atau objek yang terkoordinasi masuk ke ekstensi BL. Akses data dapat masuk ke lapisan akses data atau ekstensi akses data.

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

Ini memberi Anda sangat bagus myObject.PriceInCart()dan myObject.Save()sambil menjaga kelas Anda fokus pada data. Tentu saja untuk metode statis Anda harus memiliki MyAppDA.Create()bukan MyApp.Create().

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.