Autofixture: एक ऑब्जेक्ट ट्री बनाना जहाँ बच्चे DDD डिज़ाइन के लिए माता-पिता का संदर्भ देते हैं

मुझे लगता है कि आप पाएंगे कि Tire में मूल Car संदर्भ नहीं होना चाहिए। परिपत्र संदर्भों को खराब माना जाता है (ऑटोफिक्स्चर द्वारा, कम से कम)।

हालाँकि, यह कुछ ऐसा है जिसे मुझे भी हल करने की आवश्यकता है। मैं ईएफ मॉडल के साथ काम कर रहा हूं जिसे मैं बदल नहीं सकता, और उनके पास परिपत्र संदर्भ हैं जिन्हें मैं हटा नहीं सकता। अभी, मैं ऑटोफिक्स्चर से परहेज कर रहा हूं, लेकिन मैं इसे सामान्य रूप से हल करने में कुछ प्रयास करना चाहता हूं (यदि संभव हो)।

डोमेन संचालित डिज़ाइन करना कभी-कभी सुविधाजनक होता है क्योंकि अधिकांश तर्क डोमेन परत में होते हैं और बच्चे पर कुछ विधि को क्लीनर कार्यान्वयन के लिए संदर्भ की आवश्यकता हो सकती है।

एरिक इवांस अपनी पुस्तक "डोमेन-ड्रिवेन डिज़ाइन - टैकलिंग कॉम्प्लेक्सिटी इन द हार्ट ऑफ़ सॉफ़्टवेयर" में कहते हैं:
सर्कुलर संदर्भ तार्किक रूप से कई डोमेन में मौजूद होते हैं और कभी-कभी डिजाइन में भी आवश्यक होते हैं, लेकिन उन्हें बनाए रखना मुश्किल होता है।

साथ ही, ईएफ और फ्लुएंट एनएचबेर्नेट जैसी लोकप्रिय दृढ़ता प्रौद्योगिकियों के साथ इसे मैपिंग के लिए प्रोत्साहित किया जाता है या कम से कम अधिक आसान होता है।

इसलिए एक सुविधाजनक समाधान खोजना मेरे और अन्य लोगों के लिए उपयोगी होगा जो DDD, EF, या Fluent NHibernate कर रहे हैं।

मुझे लगता है कि @ploeh और @moodmosaic ने अतीत में यह स्पष्ट कर दिया है कि वे परिपत्र संदर्भ पसंद नहीं करते हैं और जहां भी संभव हो उनसे बचते हैं (अगर मैं गलत हूं तो मुझे सुधारें, मेरा मतलब आपके लिए बोलने का नहीं है, लेकिन यह है मेरी समझ)।

हालांकि, दोनों को ऑटोफिक्चर में योगदान स्वीकार करने के लिए जाना जाता है कि वे विशेष रूप से उपयोगी नहीं पाते हैं, बशर्ते इससे उन्हें रखरखाव और समर्थन के मुद्दों का कारण न हो (बहुत ही उचित, मुझे लगता है)।

मैं इस मुद्दे के बारे में कुछ करने की कोशिश करने और कुछ करने के लिए बहुत प्रेरित हूं (यह मानते हुए कि कुछ ऐसा है जो सामान्य रूप से उपयोगी है जो काम करेगा)।

मुझे ऐसे ढांचे पसंद हैं जो अच्छे डिजाइन को प्रोत्साहित करते हैं और मैं परिपत्र संदर्भों के साथ समस्या को समझता हूं लेकिन कभी-कभी वे तार्किक काम करते हैं। हो सकता है कि एक समाधान मिल जाए जो परिपत्र संदर्भों को प्रोत्साहित न करे लेकिन ऑटोफिक्चर की सुंदरता को नुकसान न पहुंचाए।

आपके उत्तर और सकारात्मक दृष्टिकोण के लिए धन्यवाद: +1:

हाँ, _if_ हम अच्छे सामान्य समाधान के साथ आने का प्रबंधन करते हैं, यह AutoFixture का _default_ व्यवहार नहीं होगा।

उपरोक्त CarBuilder से (वह जो काम नहीं करता), ऐसा लगता है कि आपको वास्तव में Postprocessor<Car> । क्या आपने इसकी कोशिश की?

आम तौर पर, ओआरएम कक्षाओं के लिए ऑटोफिक्चर का उपयोग करने की इच्छा एक आवर्ती विषय है, और @adamchester नोट्स के रूप में, मुझे यह काम करने में कोई समस्या नहीं है अगर इसे इस तरह से किया जा सकता है कि इससे रखरखाव या समर्थन मुद्दों का कारण नहीं बनता है।

दूसरी ओर, तीन साल से अधिक समय तक ओआरएम का उपयोग नहीं करने के कारण, इस सुविधा को आगे बढ़ाने में मेरी कोई व्यक्तिगत रुचि नहीं है, इसलिए इसे किसी और पर भरोसा करना होगा जो इस पर आगे बढ़ेगा।

परिपत्र संदर्भों की आवश्यकता के संबंध में, मैं मानता हूं कि अवधारणा वास्तविक है, लेकिन इसका मतलब यह नहीं है कि सॉफ्टवेयर डिजाइन में इसका उपयोग करना एक अच्छा विचार है। परिपत्र संदर्भ कोड को उपयोग करने और तर्क करने के लिए और अधिक कठिन बना देंगे। यदि यह अपरिहार्य था, तो हमें इसके साथ रहना होगा, लेकिन IME आप _always_ एक एपीआई को इस तरह से डिज़ाइन कर सकते हैं जो परिपत्र संदर्भों से बचता है; मुझे नहीं पता कि मैंने आखिरी बार एक परिपत्र संदर्भ के साथ एक एपीआई कब बनाया था, लेकिन यह कई साल पहले की बात है।

लेकिन ओआरएमएस के बारे में क्या, जिनकी आवश्यकता है?

ठीक है, यदि आप ओआरएम का उपयोग करते हैं, तो आप अब ऑब्जेक्ट-ओरिएंटेड कोड के साथ काम नहीं कर रहे हैं; आपका कोड मजबूत प्रक्रियात्मक तत्वों के साथ _relational_ होगा। अपनी पसंद की भाषा (सी#, आदि) को धोखा न दें।

शायद आप अभी भी इस तरह से डीडीडी कर सकते हैं, लेकिन यह डीडीडी से संबंधित होगा, ऑब्जेक्ट-ओरिएंटेड डीडीडी नहीं। मार्टिन फाउलर जिसे Transaction Script कहते हैं, उसके साथ आप समाप्त हो जाएंगे।

आपके उत्तर के लिए धन्यवाद, इसकी बहुत सराहना की जाती है: +1:

मैंने पोस्टप्रोसेसर के बारे में नहीं सुना हैलेकिन मैंने इसे आजमाया और इसे काम पर नहीं लाया, शायद मुझे कुछ याद आ रहा है। ऐसा लगता है जैसे मैं पोस्टप्रोसेसर का उपयोग करता हूं तो टाइप को चलने पर मानों के साथ प्रारंभ नहीं किया गया है।

यहाँ मेरा कोड है:

``` सी#
आंतरिक वर्ग Domain Customization : ICustomization
{
सार्वजनिक शून्य अनुकूलित (IFixture स्थिरता)
{
स्थिरता। व्यवहार। जोड़ें (नया OmitOnRecursionBehavior ());
स्थिरता। अनुकूलन। जोड़ें (
नया पोस्टप्रोसेसर(((स्थिरता) स्थिरता)। इंजन, नई कार कमांड ())
);
}
}

आंतरिक वर्ग CarCommand : ISpecimenCommand
{
सार्वजनिक शून्य निष्पादन (वस्तु नमूना, ISpecimenContext संदर्भ)
{
वर कार = कार के रूप में नमूना;
अगर (कार! = शून्य)
{
// यहां अशक्त संदर्भ अपवाद, कोई टायर नहीं, कार में कोई मान नहीं है
foreach (कार में var टायर। टायर)
{
टायर।कार = कार;
}
}
}
}
```

मार्टिन फाउलर मेरे नायकों में से एक हैं। अपने एक पोस्ट में वह एनीमिक डोमेन मॉडल के बारे में बात करता है जो कि मैं वास्तव में बचने की कोशिश कर रहा हूं। मेरी संस्थाओं के पास आवेदन में अधिकांश तर्क हैं, न कि सेवाओं (लेनदेन स्क्रिप्ट)। चूंकि संस्थाओं के पास सभी तर्क हैं, इसलिए उन्हें उनसे संबंधित कुछ डेटा की आवश्यकता हो सकती है।

डोमेन मॉडल पूरा होने के बाद मैं हमेशा दृढ़ता परत को लागू करने के साथ समाप्त करने का प्रयास करता हूं, इसलिए डेटाबेस मेरी संस्थाओं का प्रतिबिंब है, न कि दूसरी तरफ।

हालाँकि, EF/EF CodeFirst और NHibernate जैसे ORMS आपको संबंध बनाते हैं जो आपके मूल डिज़ाइन के लिए आवश्यक नहीं है और आपके डिज़ाइन को संबंधपरक बनाने के लिए आपके मूल डिज़ाइन की आवश्यकता से अधिक गोलाकार संदर्भ हैं।

ये ओआरएमएस बहुत शक्तिशाली हैं और इस "बदसूरत" को सही ठहराते हैं।
मुझे अभी और कई अन्य तकनीकों के साथ रहना होगा ताकि इस समस्या का समाधान दूसरों के लिए मददगार हो सके।

यहां एक उत्तीर्ण परीक्षा है जहां एसयूटी अपने _टायर्स_ भरे हुए हैं और प्रत्येक Tire इसके Car संदर्भित करता है:

``` सी#
[तथ्य]
सार्वजनिक शून्य परीक्षण ()
{
वर स्थिरता = नई स्थिरता ();
स्थिरता। अनुकूलित करें(सी => सी। बिना (एक्स => एक्स। कार));
स्थिरता। अनुकूलन। जोड़ें (
नया फ़िल्टरिंगनमूनाबिल्डर(
नया पोस्टप्रोसेसर (
नया मेथडइन्वोकर(
नया ModestConstructorQuery ()),
नई कारफिलर ()),
नई कार विशिष्टता ()));

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

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

}

निजी श्रेणी CarFiller : ISpecimenCommand
{
सार्वजनिक शून्य निष्पादन (वस्तु नमूना, ISpecimenContext संदर्भ)
{
अगर (नमूना == शून्य)
नया ArgumentNullException ("नमूना") फेंकें;
अगर (संदर्भ == शून्य)
नया ArgumentNullException ("संदर्भ");

    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));
    });
}

}

निजी वर्ग कार विशिष्टता: IRequestSpecification
{
पब्लिक बूल इस्सैटिस्फाइडबी (ऑब्जेक्ट रिक्वेस्ट)
{
वर अनुरोध प्रकार = प्रकार के रूप में अनुरोध;
अगर (अनुरोध टाइप == शून्य)
विवरण झूठा है;

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

}
```

मिठाई! धन्यवाद @moodmosaic , मुझे इस पहेली के कुछ टुकड़े याद आ रहे थे।
सुंदर कोड :)

आपके विचारों के लिए @adamchester और @ploeh को भी धन्यवाद।

मैं इस मुद्दे को बंद कर दूंगा, यह मेरे लिए काफी है। यदि आप अधिक सामान्य समाधान बनाना चाहते हैं तो आप इसे फिर से खोल सकते हैं।

@Moodmosaic द्वारा प्रदान किया गया नमूना कोड मुहावरेदार है, इसलिए इसे किसी विशिष्ट समस्या के विशिष्ट समाधान के रूप में आगे बढ़ना चाहिए।

डीडीडी के लिए ओआरएम का उपयोग करने की उपयुक्तता के संबंध में, मैं असहमत हूं। ओआरएम शक्तिशाली लग सकते हैं, लेकिन वास्तव में, वे बहुत ही विवश हैं। ऐसा लगता है कि एक समस्या का समाधान होता है, लेकिन कई और समस्याएं पैदा करता है।

जब डीडीडी की बात आती है, तो ब्लू बुक में वर्णित सबसे महत्वपूर्ण सामरिक पैटर्न में से एक _एग्रीगेट रूट_ की अवधारणा है। सभी ओआरएम मैंने कभी भी इस पैटर्न का स्पष्ट रूप से उल्लंघन करते हुए देखा है, क्योंकि आप किसी भी तालिका से शुरू कर सकते हैं और उस तालिका की पंक्तियों को लोड करना शुरू कर सकते हैं, और फिर संबंधित तालिकाओं से डेटा लोड करने के लिए विभिन्न 'नेविगेशन गुणों' पर चल सकते हैं। इसका मतलब है कि कोई जड़ें नहीं हैं, और इस प्रकार, डेटा का कोई स्पष्ट स्वामित्व नहीं है।

इसमें जोड़ें कि सब कुछ परिवर्तनशील है, और आपके हाथ में जल्द ही एक प्रणाली होगी, जिसके बारे में तर्क करना बहुत मुश्किल है।

वर्तमान ओआरएम के साथ एक वास्तविक समग्र रूट बनाना संभव नहीं है। एग्रीगेट रूट ही अपने डेटा को बदलने में सक्षम होना चाहिए ...

ओआरएम बाधाएं पैदा करते हैं जैसे: पैरामीटर रहित निर्माता, प्रत्येक संपत्ति के लिए बसता है और इसकी नेविगेशनल गुण सार्वजनिक हैं। इसने मुझे बहुत परेशान किया है।

मेरे वर्तमान दृष्टिकोण के साथ मैं वास्तव में भरोसा नहीं कर सकता कि मेरी लाइब्रेरी के उपयोगकर्ता इसके सकल रूट के माध्यम से डेटा बदलते हैं। भले ही कुल रूट इसे लागू कर सके, यह डेटाबेस में सीधे एसक्यूएल अपडेट को नहीं रोकेगा ...

SqlServer और रिलेशनल डेटाबेस पर अटके रहने से मुझे दूसरा रास्ता खोजने में मदद नहीं मिली है। शायद मुझे एक बेहतर तरीके की तलाश में रहना चाहिए।

फिर भी, मुझे लगता है कि मैंने डीडीडी के साथ जो एप्लिकेशन बनाए हैं, वे बदलने और बनाए रखने के लिए अधिक लचीले हैं। इसका एक हिस्सा टीडीडी और अनुभव की मदद भी हो सकता है।

आपके विचारों के लिए धन्यवाद: +1:

मैंने देखा है कि यदि आपके पास फिलर द्वारा संसाधित किए जा रहे प्रकार के लिए .कस्टमाइज़ कॉल है जिसके कारण फिलर को अनदेखा कर दिया जाता है। उदाहरण के लिए 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));

तो विवरण पर दावा विफल रहता है। इसके अभी भी स्वतः उत्पन्न होने के कारण, अनुकूलन को अनदेखा कर दिया जाता है। चीजों के बारे में मेरी तनावपूर्ण समझ के आधार पर मैंने उम्मीद की होगी कि फिलर को पारित नमूना संगीतकार का उपयोग करके बनाया गया हो।

संपादित करें अब मैं देख रहा हूं कि 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);
            }
        }

आपका सामान्य समाधान बहुत अच्छा था!
मैंने इसे अधिक प्रकार के सुरक्षित कोड के लिए संपत्ति अभिव्यक्तियों का उपयोग करने के लिए अद्यतन किया और एक सामान्य अनुकूलन बनाया। मैंने इसका उपयोग नहीं किया, लेकिन मैंने सोचा कि मैं इसे साझा करूंगा क्योंकि मैंने इसे पहले ही लिखा था। :-)

उदाहरण। कैशरजिस्टर में रसीदों के साथ सूची है। रसीद का कैशरजिस्टर का पिछला संदर्भ है

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);
    }
}