.NET 프로그래밍 및 POCO 클래스

9

오늘 밤에 변경해야 할 응용 프로그램을 숙고하면서 생각을하고 있었고 생각하게했습니다. Entity Framework 엔터티는 POCO (Plain old CLR Objects)이며 ASP.NET MVC에 사용되는 모델도 일반적으로 POCO입니다. 이것은 기본적으로 속성이 아니라 메서드를 의미합니다.

이제 OO 프로그래밍은 일반적으로 객체가 객체의 기능과 메소드를 포함하는 기능을 캡슐화 할 수있게하여 다형성이 발생할 수 있도록합니다. POCO 클래스가 증가함에 따라 일반 리포지토리와 같은 디자인 패턴이 더욱 대중화되었습니다. 과거에 객체가 자체 CRUD 작업을 수행했을 때 이제는 저장소에 있습니다.

CRUD 작업이 개체에서 분리되어 분리 될 수있게하거나 OO 작업이 과거에 개체 수준이 아니어야했던 잘못된 OO의 발전 일 뿐입니 까? 도대체, 아마도 둘 다 완벽하게 합법적이며 항상 그렇습니다. 그것은 단지 내가 생각하게 만든 관찰이므로 다른 의견을 구할 것이라고 생각했습니다.

design-patterns object-oriented .net

— 제임스
소스

9

Wyatt가 말했듯이 POCO와 POJO는 결코 방법을 의미하지 않습니다. 나는 그것이 비 POCO와 비 POJO가 무엇인지 모르는 것에서 비롯된 것이라고 생각합니다.

ORM 기술의 첫 번째 버전은 단순히 개체가 프레임 워크 자체에서 일부 기본 클래스를 상속해야했기 때문에 POCO 및 POJO가 아닙니다. Java, Entity Beans의 경우 Entity Framework의 경우 첫 번째 버전에서 POCO가 가능하지 않았으며 각 엔티티는 Entity기본 클래스 를 상속해야했습니다 .

이 요구 사항으로 인해 데이터 모델이 지속성 기술에 의존하게되므로 많은 일이 어렵거나 불가능 해집니다. 모델 단위 테스트와 같은 것들은 실제로 불가능한 것으로 입증 된 bean / entity 프레임 워크를 조롱해야합니다. 또한 지속성 기술이 다른 모델을 사용할 수 없거나 모바일 환경과 같이 다른 컨텍스트에서 모델을 사용할 수 없습니다.

따라서 POCO가 존재하지 않는 방법에 대한 가정은 잘못되었습니다. POCO는 모델을 지속성 기술과 분리하여 사용할 수있게하는 것입니다.

당신이 말하는 것은 아마도 Anemic Domain Model 과 적절한 도메인 모델 에 가깝다 는 것입니다 .

— 크게 기쁘게
소스

당신은 옳습니다. 그것은 기사를 읽은 Anemic Domain Model과 비슷합니다.

— James

4

POCO는 결코 방법이 없음을 의미하지는 않지만 대부분의 예제는 주로 속성을 처리하고 메서드를 무시하는 많은 MVC 자동 바인딩 기능을 사용합니다.

모델 객체에 퍼시스턴스가 내장되어 있으면 우려의 분리를 위반하고 데이터베이스를 세우지 않고 객체를 단위 테스트하는 등의 작업을 수행하기가 매우 어렵습니다. 모델 객체의 함수가 아니라 리포지토리와 같은 다른 클래스 인 경우 함수입니다.

— 와이엇 바넷
소스

뭐라고? poco는 내 경험에 전혀 방법을 암시하지 않습니다. 그렇지 않으면 사용에 따라 엔티티 또는 모델 또는 뷰 모델입니다.

— Telastyn

2

지난번에 Plain Old C-Sharp Object가 메소드를 가질 수 있는지 확인했습니다. 이 용어는 유형이 지정된 데이터 세트와 같은 물건이 있거나 POCO가 아닌 특정 클래스에서 상속되는 모델 객체를 가져야했던 나쁜 시대에 나왔습니다.

— Wyatt Barnett

메소드가 인터페이스를 승인하도록하여 메소드를 오브젝트에 유지하면서 우려 분리가 달성 될 수 있습니다. 해당 인터페이스는 객체의 CRUD 작업을 처리 할 수있는 유형을 지정합니다.

— James

1

각각의 장점을 가진 두 가지 다른 접근 방식.

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

— 노먼 노블
소스

0

나는 최근에 이와 같은 것들을 위해 확장 메소드 를 사용 하고있다.

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

— 제프리 토마스
소스