Autofixture: DDD 설계를 위해 자식이 부모를 참조하는 개체 트리 만들기

Tire 에는 부모 Car 대한 참조가 없어야 한다고 생각합니다. 순환 참조는 나쁜 것으로 간주됩니다(최소한 autofixture에 의해).

그러나 이것은 또한 내가 해결해야 할 문제입니다. 변경할 수 없는 EF 모델로 작업 중이며 제거할 수 없는 순환 참조가 있습니다. 지금은 autofixture를 피하고 있지만 가능한 경우 일반적으로 이 문제를 해결하는 데 약간의 노력을 기울이고 싶습니다.

Domain Driven Design을 수행하면 대부분의 논리가 도메인 계층에 있고 자식에 대한 일부 메서드는 보다 명확한 구현을 위해 참조가 필요할 수 있으므로 때때로 편리합니다.

Eric Evans는 그의 책 " Domain-Driven Design - Tackling Complexity in the Heart of Software"에서 다음과 같이 말했습니다.
순환 참조는 논리적으로 많은 영역에 존재하며 때로는 설계에도 필요하지만 유지 관리가 까다롭습니다.

또한 EF 및 Fluent NHibernate와 같은 인기 있는 지속성 기술을 사용하면 매핑이 권장되거나 최소한 더 쉽습니다.

따라서 편리한 솔루션을 찾는 것은 DDD, EF 또는 Fluent NHibernate를 사용하는 나와 다른 사람들에게 도움이 될 것입니다.

@ploeh 와 @moodmosaic 은 과거에 순환 참조를 좋아하지 않으며 가능한 한 피한다고 분명히 밝혔습니다. 내 이해).

그러나 둘 다 AutoFixture에 대한 기여를 수용하는 것으로 알려져 있지만 유지 관리 및 지원 문제를 일으키지 않는 한 특별히 유용하지 않다고 생각합니다(매우 공정하다고 생각합니다).

나는 이 문제에 대해 뭔가를 시도하고 하고자 하는 동기가 매우 큽니다(일반적으로 작동하는 유용한 것이 있다고 가정).

나는 좋은 디자인을 장려하는 프레임워크를 좋아하고 순환 참조의 문제를 이해하지만 때로는 그것이 논리적인 일입니다. 순환 참조를 권장하지 않지만 AutoFixture의 아름다움을 해치지 않는 솔루션을 찾을 수 있습니다.

귀하의 답변과 긍정적인 태도에 감사드립니다 :+1:

예, _만약_ 우리가 적절한 일반 솔루션을 찾아낼 수 있다면, 그것은 AutoFixture의 _default_ 동작이 아닐 것입니다.

위의 CarBuilder (작동하지 않는 것)에서 실제로 필요한 것이 Postprocessor<Car> 것처럼 보입니다. 당신은 그것을 시도 했습니까?

일반적으로 ORM 클래스에 AutoFixture를 사용하려는 욕구는 되풀이되는 주제이며 @adamchester가 언급

반면에 ORM을 3년 이상 사용하지 않았기 때문에 이 기능을 추구하는 데 개인적인 관심이 없기 때문에 다른 사람이 주도해야 합니다.

순환 참조의 필요성과 관련하여 나는 그 개념이 현실적이라는 데 동의하지만, 그것이 소프트웨어 디자인에서 그것을 사용하는 것이 좋은 생각이라는 것을 의미하지는 않습니다. 순환 참조는 코드를 사용하고 추론하기 훨씬 더 어렵게 만듭니다. 피할 수 없는 상황이라면 그에 따라 살아야 하지만 IME는 순환 참조를 피하는 방식으로 API를 _항상_ 설계할 수 있습니다. 순환 참조를 사용하여 API를 마지막으로 만든 것이 언제인지 모르겠지만 수년 전입니다.

그러나 이를 필요로 하는 ORMS는 어떻습니까?

ORM을 사용한다면 더 이상 객체 지향 코드로 작업하지 않습니다. 귀하의 코드는 강력한 절차적 요소를 포함하는 _relational_이 될 것입니다. 언어 선택(C# 등)에 속지 마십시오.

아마도 이 방법으로 DDD를 수행할 수 있지만 객체 지향 DDD가 아닌 관계형 DDD가 될 것입니다. Martin Fowler가 트랜잭션 스크립트 라고 부르는 것으로 끝납니다.

답변 감사합니다. 감사합니다 :+1:

PostProcessor에 대해 들어본 적이 없습니다.그러나 나는 그것을 시도했고 그것을 작동시키지 못했습니다. 아마도 내가 뭔가를 놓치고있을 것입니다. PostProcessor를 사용하는 것처럼 유형이 실행될 때 값으로 초기화되지 않은 것 같습니다.

내 코드는 다음과 같습니다.

``` C#
내부 클래스 DomainCustomization : ICustomization
{
public void 커스터마이징(IFixture 조명기)
{
Fixture.Behaviors.Add(new OmitOnRecursionBehavior());
Fixture.Customizations.Add(
새로운 포스트 프로세서(((Fixture) Fixture).Engine, 새로운 CarCommand())
);
}
}

내부 클래스 CarCommand : ISpecimenCommand
{
public void Execute(객체 표본, ISpecimenContext 컨텍스트)
{
var car = Car로 표본;
if (자동차 != null)
{
//여기서 null 참조 예외, 타이어 없음, 자동차 설정에 값 없음
foreach (자동차 타이어의 var.Tires)
{
타이어.자동차 = 자동차;
}
}
}
}
```

마틴 파울러는 제 영웅 중 한 명입니다. 그의 게시물 중 하나에서 그는 정확히 내가 피하려고 하는 빈혈 도메인 모델에 대해 이야기합니다. 내 엔터티에는 서비스(트랜잭션 스크립트)가 아닌 응용 프로그램에 대부분의 논리가 있습니다. 엔터티에는 모든 논리가 있으므로 관련 데이터가 필요할 수 있습니다.

나는 항상 도메인 모델이 완료된 후 지속성 계층을 구현하는 것으로 끝내려고 노력하므로 데이터베이스가 내 엔티티를 반영하는 것이 아닙니다.

그러나 EF/EF CodeFirst 및 NHibernate와 같은 ORMS는 설계를 관계형으로 만드는 원래 설계에 필요한 것보다 더 많은 순환 참조와 엔티티에 필요하지 않은 관계를 생성합니다.

이 ORMS는 매우 강력하며 이 "추함"을 정당화합니다.
나는 이 문제에 대한 해결책이 다른 사람들에게 도움이 될 수 있도록 당분간 이러한 기술과 다른 많은 기술과 함께 살아야 할 것입니다.

다음은 _Tires_가 채워진 SUT가 생성되고 각 Tire 가 Car 참조하는 통과 테스트입니다.

``` C#
[사실]
공개 무효 테스트()
{
var 고정 장치 = new Fixture();
정착물.사용자 정의(c => c.Without(x => x.Car));
Fixture.Customizations.Add(
새로운 FilteringSpecimenBuilder(
새로운 포스트 프로세서(
새로운 메서드 호출자(
새로운 ModestConstructorQuery()),
새로운 CarFiller()),
새로운 CarSpecification()));

var car = fixture.Create<Car>();

Assert.NotEmpty(car.Tires);
Array.ForEach(car.Tires.ToArray(), x => Assert.NotNull(x.Car));

}

개인 클래스 CarFiller : ISpecimenCommand
{
public void Execute(객체 표본, ISpecimenContext 컨텍스트)
{
if (시편 == null)
새로운 ArgumentNullException("샘플") 던지기;
if (컨텍스트 == null)
새로운 ArgumentNullException("context") 던지기;

    var car = specimen as Car;
    if (car == null)
        throw new ArgumentException(
            "The specimen must be an instance of Car.",
            "specimen");

    Array.ForEach(car.GetType().GetProperties(), x =>
    {
        if (x.Name == "Tires")
        {
            var tires =
                ((IEnumerable<object>)context
                    .Resolve(new MultipleRequest(typeof(Tire))))
                        .Cast<Tire>().ToArray();
            Array.ForEach(tires, tire => tire.Car = car);
            x.SetValue(car, tires.ToList());
        }
        else x.SetValue(car, context.Resolve(x.PropertyType));
    });
}

}

개인 클래스 CarSpecification : IRequestSpecification
{
public bool IsSatisfiedBy(객체 요청)
{
var requestType = 유형으로 요청;
if (요청 유형 == null)
거짓을 반환합니다.

    return typeof(Car).IsAssignableFrom(requestType);
}

}
```

달콤한! @moodmosaic 감사합니다. 이 퍼즐에서 몇 장의 사진이 누락되었습니다.
아름다운 코드 :)

또한 의견을 주신 @adamchester 와 @ploeh에게도 감사드립니다.

이 문제를 종료하겠습니다. 이 정도면 충분합니다. 보다 일반적인 솔루션을 만들려면 이것을 다시 열 수 있습니다.

@moodmosaic에서 제공하는 샘플 코드는 관용적이므로 특정 문제에 대한 특정 솔루션으로 나아가야 합니다.

DDD에 ORM을 사용하는 것이 적절하다는 점에 대해서는 동의하지 않습니다. ORM은 강력해 보이지만 실제로는 매우 제한적입니다. 문제를 해결하는 것처럼 보이지만 더 많은 문제를 만듭니다.

DDD와 관련하여 블루 북에서 설명하는 가장 중요한 전술 패턴 중 하나는 _Aggregate Root_의 개념입니다. 내가 본 모든 ORM은 이 패턴을 노골적으로 위반합니다. 지정된 테이블에서 시작하여 해당 테이블의 행 로드를 시작한 다음 다양한 '탐색 속성'을 사용하여 연결된 테이블에서 데이터를 로드할 수 있기 때문입니다. 이는 루트가 없으므로 데이터에 대한 명확한 소유권이 없음을 의미합니다.

여기에 모든 것이 변경 가능하다는 점을 추가하면 곧 시스템을 갖게 될 것입니다. 이는 추론하기 매우 어렵습니다.

현재 ORM으로 진정한 집계 루트를 만드는 것은 불가능합니다. 집계 루트는 데이터를 변경할 수 있는 유일한 루트여야 합니다...

ORM은 매개 변수가 없는 생성자, 각 속성에 대한 설정자 및 탐색 속성 공개와 같은 제약 조건을 만듭니다. 이것은 나를 매우 짜증나게 했다.

현재 접근 방식으로는 내 라이브러리의 사용자가 집계 루트를 통해 데이터를 변경한다는 사실을 믿을 수 없습니다. Aggregate Root가 이것을 시행할 수 있더라도 데이터베이스에서 직접적인 SQL 업데이트를 방지하지 못할 것입니다...

SqlServer 및 관계형 데이터베이스에 갇힌 것은 다른 방법을 찾는 데 도움이 되지 않았습니다. 더 나은 방법을 계속 찾아야 할 수도 있습니다.

그럼에도 불구하고 DDD로 만든 응용 프로그램이 더 유연하게 변경하고 유지 관리할 수 있다고 생각합니다. 그 중 일부는 TDD와 경험의 도움이 될 수도 있습니다.

생각해주셔서 감사합니다 :+1:

필러에 의해 처리되는 유형에 대한 .Customize 호출이 있는 경우 필러가 무시되도록 하는 것으로 나타났습니다. 예: fixture.Customize<Car>(c => c.Without(x => x.Doors))

나는 이것을 다음과 같이 결합하려고 노력했다.

var fixture = new Fixture();
            fixture.Customize<Tire>(c => c.Without(x => x.Car));
            ///fixture.Customize<Car>(c => c.Without(x => x.Doors));
            fixture.Customizations.Add(
                new FilteringSpecimenBuilder(
                    new Postprocessor(
                        SpecimenBuilderNodeFactory.CreateComposer<Car>().WithAutoProperties(!fixture.OmitAutoProperties)
                        .With(x=>x.Description, "Wee")
                        ,
                        new CarFiller()),
                    new CarSpecification()));


            var car = fixture.Create<Car>();

            Assert.Equal("Wee", car.Description);
            Assert.NotEmpty(car.Tires);
            Array.ForEach(car.Tires.ToArray(), x => Assert.NotNull(x.Car));
            Array.ForEach(car.Tires.ToArray(), x => Assert.True(x.Car == car));

따라서 설명에 대한 어설션이 실패합니다. 여전히 자동 생성되고 사용자 정의는 무시됩니다. 나의 긴장된 이해를 바탕으로 필러에 전달된 시편이 Composer를 사용하여 생성된 것으로 예상했을 것입니다.

편집 이제 else x.SetValue(car, context.Resolve(x.PropertyType)) 가 다른 속성을 자동으로 생성하고 있음을 알 수 있습니다. 건배

더 일반화된 버전은 다음과 같습니다.

private class CollectionBackReferenceFiller<T, TElement> : ISpecimenCommand
            where T : class
        {
            private readonly string _collectionProperty;
            private readonly Action<TElement, T> _backReferenceSetter;

            public CollectionBackReferenceFiller(string collectionProperty, Action<TElement, T> backReferenceSetter)
            {
                _collectionProperty = collectionProperty;
                _backReferenceSetter = backReferenceSetter;
            }

            public void Execute(object specimen, ISpecimenContext context)
            {
                if (specimen == null)
                    throw new ArgumentNullException("specimen");
                if (context == null)
                    throw new ArgumentNullException("context");

                var typedSpecimen = specimen as T;
                if (typedSpecimen == null)
                    throw new ArgumentException(
                        "The specimen must be an instance of " + typeof(T).Name,
                        "specimen");

                Array.ForEach(typedSpecimen.GetType().GetProperties(), x =>
                {
                    if (x.Name == _collectionProperty)
                    {
                        var elements =
                            ((IEnumerable<object>)context
                                .Resolve(new MultipleRequest(typeof(TElement))))
                                    .Cast<TElement>().ToArray();
                        Array.ForEach(elements, e => _backReferenceSetter(e, typedSpecimen));

                        x.SetValue(typedSpecimen, elements.ToList());
                    }
                });
            }
        }

        private class TypeSpecification<T> : IRequestSpecification
        {
            public bool IsSatisfiedBy(object request)
            {
                var requestType = request as Type;
                if (requestType == null)
                    return false;

                return typeof(T).IsAssignableFrom(requestType);
            }
        }

귀하의 일반 솔루션은 훌륭했습니다!
보다 유형이 안전한 코드에 대해 속성 식을 사용하도록 업데이트하고 일반 사용자 지정을 만들었습니다. 결국 사용하지 않게 되었지만 이미 작성했기 때문에 공유할 생각입니다. :-)

예시. CashRegister에는 영수증이 있는 목록이 있습니다. 영수증에는 CashRegister에 대한 역 참조가 있습니다.

public class CashRegister : EntityBase
{
    public List<Receipt> Receipts { get; set; }
}

public class Receipt : EntityBase
{
    public CashRegister CashRegister { get; set; }
}

사용자 정의 사용:
new BackReferenceCustomization<CashRegister, Receipt>(cashRegister => cashRegister.Receipts, receipt => receipt.CashRegister)

사용자 정의:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;
using AutoFixture;
using AutoFixture.Kernel;

public class BackReferenceCustomization<TTypeWithList, TTypeWithBackReference> : ICustomization where TTypeWithList : class
{
    private readonly Expression<Func<TTypeWithList, List<TTypeWithBackReference>>> _collectionPropertyExpression;
    private readonly Expression<Func<TTypeWithBackReference, TTypeWithList>> _backReferencePropertyExpression;

    public BackReferenceCustomization(
        Expression<Func<TTypeWithList, List<TTypeWithBackReference>>> collectionPropertyExpression,
        Expression<Func<TTypeWithBackReference, TTypeWithList>> backReferencePropertyExpression)
    {
        _collectionPropertyExpression = collectionPropertyExpression;
        _backReferencePropertyExpression = backReferencePropertyExpression;
    }

    public void Customize(IFixture fixture)
    {
        fixture.Customize<TTypeWithBackReference>(c => c.Without(_backReferencePropertyExpression));
        fixture.Customizations.Add(
            new FilteringSpecimenBuilder(
                new Postprocessor(
                    new MethodInvoker(new ModestConstructorQuery()),
                    new CollectionBackReferenceFiller<TTypeWithList, TTypeWithBackReference>(_collectionPropertyExpression, _backReferencePropertyExpression)
                ),
                new TypeSpecification<TTypeWithList>()
            )
        );
    }
}

public class CollectionBackReferenceFiller<TTypeWithList, TTypeWithBackReference> : ISpecimenCommand where TTypeWithList : class
{
    private readonly Expression<Func<TTypeWithList, List<TTypeWithBackReference>>> _collectionPropertyExpression;
    private readonly Expression<Func<TTypeWithBackReference, TTypeWithList>> _backReferencePropertyExpression;

    public CollectionBackReferenceFiller(Expression<Func<TTypeWithList, List<TTypeWithBackReference>>> collectionPropertyExpression, Expression<Func<TTypeWithBackReference, TTypeWithList>> backReferencePropertyExpression)
    {
        _collectionPropertyExpression = collectionPropertyExpression;
        _backReferencePropertyExpression = backReferencePropertyExpression;
    }

    public void Execute(object specimen, ISpecimenContext context)
    {
        if (specimen == null)
            throw new ArgumentNullException(nameof(specimen));
        if (context == null)
            throw new ArgumentNullException(nameof(context));

        if (!(specimen is TTypeWithList typedSpecimen))
            throw new ArgumentException(
                "The specimen must be an instance of " + typeof(TTypeWithList).Name,
                nameof(specimen));

        var elements =
            ((IEnumerable<object>)context
                .Resolve(new MultipleRequest(typeof(TTypeWithBackReference))))
            .Cast<TTypeWithBackReference>().ToList();

        var collectionProperty = (PropertyInfo)((MemberExpression)_collectionPropertyExpression.Body).Member;
        collectionProperty.SetValue(typedSpecimen, elements);

        var backReferenceProperty = (PropertyInfo)((MemberExpression)_backReferencePropertyExpression.Body).Member;

        foreach (var element in elements)
        {
            backReferenceProperty.SetValue(element, typedSpecimen);
        }

        var otherProperties = typedSpecimen.GetType().GetProperties().Where(p => !p.Equals(collectionProperty) && p.SetMethod != null);
        foreach (var property in otherProperties)
        {
            property.SetValue(typedSpecimen, context.Resolve(property.PropertyType));
        }
    }
}

public class TypeSpecification<T> : IRequestSpecification
{
    public bool IsSatisfiedBy(object request)
    {
        var requestType = request as Type;
        if (requestType == null)
            return false;

        return typeof(T).IsAssignableFrom(requestType);
    }
}