.NET Programming และคลาส POCO

ฉันมีความคิดในคืนนี้ขณะที่ไตร่ตรองเกี่ยวกับแอปพลิเคชันบางอย่างที่ฉันต้องเปลี่ยนและทำให้ฉันคิดได้ เอนทิตีกรอบเอนทิตีเป็น POCO (ธรรมดา CLR วัตถุเก่า) และรูปแบบที่ใช้ใน ASP.NET MVC ก็มักจะ POCO นี่หมายถึงคุณสมบัติโดยทั่วไปไม่มีวิธีการ

ตอนนี้การเขียนโปรแกรม OO ตามปกติจะอนุญาตให้วัตถุห่อหุ้มการทำงานของมันซึ่งรวมถึงคุณสมบัติของมันเช่นเดียวกับวิธีการของมันซึ่งจะช่วยให้เกิดความหลากหลาย ด้วยการเพิ่มขึ้นของคลาส POCO ที่ใช้รูปแบบการออกแบบเช่นที่เก็บทั่วไปกลายเป็นที่นิยมมากขึ้น เมื่อก่อนวัตถุของฉันจะมีการดำเนินการ CRUD ของตัวเองตอนนี้ฉันมีพวกเขาในพื้นที่เก็บข้อมูล

นี่เป็นเพียงวิวัฒนาการใน OO ที่การดำเนินการ CRUD ถูกลบออกจากวัตถุเพื่อให้สามารถแยกหรือการดำเนินการ CRUD อาจไม่ได้อยู่ในระดับวัตถุในอดีตและฉันผิด ห่าบางทีทั้งสองอย่างถูกต้องตามกฎหมายและได้รับเสมอ มันเป็นเพียงข้อสังเกตที่ทำให้ฉันคิดดังนั้นฉันจึงคิดว่าจะหาความคิดเห็นอื่น

ดังที่ไวแอตกล่าวว่า POCO และ POJO ไม่ว่าจะด้วยวิธีใดก็ตาม ฉันคิดว่าเกิดจากการไม่รู้ว่าไม่ใช่ POCO และที่ไม่ใช่ POJO

เทคโนโลยี ORM เวอร์ชันแรกไม่ใช่ POCO และ POJO เพียงเพราะต้องการเอนทิตีเพื่อสืบทอดคลาสพื้นฐานบางส่วนจากเฟรมเวิร์ก ในกรณีของ Java, Entity Beans. ในกรณีของ Entity Framework, POCO นั้นเป็นไปไม่ได้ในเวอร์ชันแรกและแต่ละเอนทิตีจะต้องสืบทอด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()