.NET编程和POCO类

今晚我在思考需要更改的某些应用程序时思考了一下，这让我开始思考。实体框架实体是POCO（普通的旧CLR对象），而ASP.NET MVC中使用的模型通常也是POCO。这基本上意味着仅属性，没有方法。

现在，OO编程通常允许对象封装其功能，包括其属性和方法，这允许多态发生。随着使用POCO类的兴起，通用存储库之类的设计模式变得越来越流行。过去，当我的对象有自己的CRUD操作时，现在将它们放在存储库中。

这仅仅是OO的发展而已，它从对象中删除了CRUD操作以使它们解耦，或者CRUD操作过去不应该处于对象级别，而我错了吗？哎呀，也许两者都是合法的，而且一直都是。这只是一个让我思考的观察，所以我想寻求其他意见。

正如怀亚特所说，POCO和POJO绝不意味着没有方法。我认为这是由于不知道什么是非POCO和非POJO。

ORM技术的第一个版本不是POCO和POJO，仅仅是因为它要求实体从框架本身继承一些基类。对于Java，是Entity Bean。对于Entity Framework，在第一个版本中POCO不可能，并且每个实体都必须继承Entity基类。

这种要求使您的数据模型依赖于持久性技术，这使很多事情变得困难或不可能。诸如单元测试模型之类的事情需要模拟bean /实体框架，事实证明这是不可能的。您也不能使用具有不同持久性技术的模型，也不能在移动环境中的不同上下文中使用模型。

因此，您认为POCO关于方法不存在的假设是错误的。POCO即将能够与持久性技术分离地使用该模型。

您所谈论的可能与Anemic Domain Model和适当的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()。