[C#] تصميم - أين يجب تسجيل الكائنات عند استخدام وندسور


Answers

في حين أن إجابة مارك كبيرة لسيناريوهات الويب، فإن الخلل الرئيسي في تطبيقه على جميع الأبنية (أي العميل الغني - أي: وف، وينفورمز، يوس، إلخ) هو الافتراض بأن جميع المكونات اللازمة لعملية ما يمكن إنشاؤها ذات مرة.

لخوادم الويب هذا منطقي لأن كل طلب هو قصير للغاية، ويتم إنشاء وحدة تحكم مفك ASP.NET من قبل الإطار الأساسي (أي رمز المستخدم) لكل طلب يأتي في. وبالتالي وحدة تحكم وجميع تبعياتها يمكن أن تتكون بسهولة من خلال إطار عمل شركة دي، وهناك القليل جدا من تكاليف الصيانة للقيام بذلك. لاحظ أن إطار الويب هو المسؤول عن إدارة عمر وحدة التحكم ولجميع الأغراض عمر جميع تبعياتها (والتي سيقوم إطار دي بإنشاء / حقن لك على إنشاء وحدة تحكم). فمن الغرامة تماما أن تبعيات تعيش لمدة الطلب ورمز المستخدم الخاص بك لا تحتاج إلى إدارة عمر المكونات والمكونات الفرعية نفسها. لاحظ أيضا أن خوادم الويب عديمي الجنسية عبر طلبات مختلفة (باستثناء حالة جلسة العمل، ولكن هذا غير ذي صلة بهذه المناقشة) وأنك لا تمتلك مثيلات تحكم / تحكم الطفل متعددة التي تحتاج إلى العيش في نفس الوقت لخدمة طلب واحد.

في تطبيقات الغنية العميل ولكن هذا هو الحال كثيرا ليس كذلك. إذا كنت تستخدم بنية مفك / مففم (التي يجب عليك!) جلسة المستخدم هو طويلة-- الحياة وحدات تحكم إنشاء وحدات تحكم فرعية / الأخوة تحكم كما يتنقل المستخدم من خلال التطبيق (انظر ملاحظة حول مففم في الأسفل). التشبيه إلى العالم على شبكة الإنترنت هو أن كل إدخال المستخدم (انقر فوق زر، عملية تنفيذها) في التطبيق غنية العميل هو ما يعادل طلب تلقيها من قبل إطار الويب. الفرق الكبير ولكن هو أن تريد وحدات التحكم في التطبيق غنية العميل للبقاء على قيد الحياة بين العمليات (من الممكن جدا أن المستخدم يفعل عمليات متعددة على نفس الشاشة - التي تحكمها وحدة تحكم معينة) وأيضا أن وحدات تحكم فرعية الحصول على التي تم إنشاؤها وتدميرها كما يقوم المستخدم بتنفيذ إجراءات مختلفة (فكر في عنصر تحكم علامة التبويب التي تخلق ببطء علامة التبويب إذا كان المستخدم يتنقل إلى ذلك، أو قطعة من واجهة المستخدم التي تحتاج فقط للحصول على تحميل إذا كان المستخدم ينفذ إجراءات معينة على الشاشة).

كل من هذه الخصائص تعني أنه رمز المستخدم الذي يحتاج إلى إدارة عمر وحدات التحكم / وحدات التحكم الفرعية، وأنه يجب ألا يتم إنشاء جميع وحدات تحكم التحكم مقدما (أي: وحدات تحكم فرعية ونماذج عرض ومكونات عرض تقديمي أخرى إلخ. ). إذا كنت تستخدم إطار دي للقيام بهذه المسؤوليات سوف ينتهي بك الأمر ليس فقط الكثير من التعليمات البرمجية حيث أنها لا تنتمي (انظر: منشئ الإفراط في حقن المضادة للنمط ) ولكن سوف تحتاج أيضا لتمرير على طول حاوية التبعية في جميع أنحاء معظم طبقة العرض التقديمي بحيث يمكن للمكونات الخاصة بك استخدامه لإنشاء مكوناتها الفرعية عند الحاجة.

لماذا من سوء أن رمز المستخدم الخاص بي لديه حق الوصول إلى حاوية دي؟

1) الحاوية التبعية يحمل إشارات إلى الكثير من المكونات في التطبيق الخاص بك. تمرير هذا الولد السيئ في جميع أنحاء كل مكون يحتاج إلى إنشاء / إدارة المكون الفرعي أنوتر هو ما يعادل استخدام الكرات في العمارة الخاصة بك. أسوأ من أي عنصر فرعي يمكن أيضا تسجيل مكونات جديدة في الحاوية حتى وقت قريب بما فيه الكفاية سوف تصبح تخزين عالمي كذلك. سيقوم المطورين رمي الأشياء في الحاوية فقط لتمرير البيانات بين المكونات (سواء بين وحدات تحكم الأخوة أو بين الهرمية تحكم عميق - أي: وحدة تحكم سلف يحتاج إلى انتزاع البيانات من وحدة تحكم الأجداد). لاحظ أنه في عالم الويب حيث لا يتم تمرير الحاوية حول رمز المستخدم هذه ليست مشكلة.

2) المشكلة الأخرى مع حاويات التبعية مقابل محددات الخدمة / المصانع / مثيل كائن مباشر هو أن حل من حاوية يجعل من غامضة تماما ما إذا كنت إنشاء مكون أو ببساطة إعادة واحدة موجودة. بدلا من ذلك يتم ترك ما يصل إلى تكوين مركزي (أي: بوتسترابر / تكوين الجذر) لمعرفة ما هو عمر المكون. في بعض الحالات هذا على ما يرام (أي: وحدات تحكم ويب، حيث أنه ليس رمز المستخدم الذي يحتاج إلى إدارة عمر المكون ولكن إطار معالجة طلب وقت التشغيل نفسه). هذا هو المشكلة للغاية ولكن عندما يجب أن تصميم مكوناتك تشير إلى ما إذا كان من مسؤوليتها لإدارة عنصر وما يجب أن يكون عمرها (مثال: التطبيق الهاتف للملوثات العضوية الثابتة ورقة تطلب من المستخدم للحصول على بعض المعلومات.هذا يتحقق من قبل وحدة تحكم إنشاء وحدة تحكم فرعية التي تحكم ورقة تراكب.بمجرد أن يدخل المستخدم بعض المعلومات يتم استقالتها ورقة، ويتم إرجاع عنصر تحكم إلى وحدة تحكم الأولي، والتي لا تزال تحافظ على الدولة من ما كان يقوم به المستخدم قبل). إذا تم استخدام دي لحل وحدة التحكم الفرعية ورقة انها غامضة ما هو عمرها ينبغي أن يكون أو الذين يجب أن تكون مسؤولة عن إدارته (وحدة تحكم بدء). قارن ذلك بالمسؤولية الصريحة التي يمليها استخدام آليات أخرى.

السيناريو ألف:

// not sure whether I'm responsible for creating the thing or not
DependencyContainer.GimmeA<Thing>()

السيناريو باء:

// responsibility is clear that this component is responsible for creation

Factory.CreateMeA<Thing>()
// or simply
new Thing()

السيناريو جيم:

// responsibility is clear that this component is not responsible for creation, but rather only consumption

ServiceLocator.GetMeTheExisting<Thing>()
// or simply
ServiceLocator.Thing

كما ترون دي يجعل من غير الواضح من هو المسؤول عن إدارة مدى الحياة من المكون الفرعي.

ملاحظة: من الناحية الفنية العديد من أطر دي لديها بعض الطريق لخلق مكونات لزيلي (انظر: كيف لا تفعل حقن التبعية - حاوية ثابتة أو سينغليتون ) الذي هو أفضل بكثير من تمرير الحاوية حولها، ولكن كنت لا تزال تدفع تكلفة تحوير التعليمات البرمجية الخاصة بك لتمرير حول وظائف الخلق في كل مكان، كنت تفتقر إلى الدعم من المستوى الأول لتمرير في معلمات منشئ صالح أثناء الإنشاء، وفي نهاية اليوم كنت لا تزال تستخدم آلية غير مباشرة دون داع في الأماكن التي تكون فيها الفائدة الوحيدة لتحقيق قابلية الاختبار ، والتي يمكن تحقيقها بطرق أفضل وأبسط (انظر أدناه).

ماذا يعني كل هذا؟

وهذا يعني أن شركة دي مناسبة لسيناريوهات معينة، وغير مناسبة للآخرين. في التطبيقات الغنية العميل يحدث أن تحمل الكثير من سلبيات دي مع عدد قليل جدا من الصعود. وعلاوة على ذلك التطبيق الخاص بك جداول في تعقيد أكبر تكاليف الصيانة سوف تنمو. كما أنه يحمل إمكانات خطيرة لسوء الاستخدام، وهذا يتوقف على مدى ضيق فريقك الاتصالات وعمليات مراجعة التعليمات البرمجية، يمكن أن يكون في أي مكان من غير قضية إلى تكلفة الدين التكنولوجيا الحادة. هناك أسطورة تجول حول تلك المواقع أو المصانع الخدمة أو إنستانتياتيون القديمة الجيدة هي آليات سيئة إلى حد ما و عفا عليها الزمن ببساطة لأنها قد لا تكون الآلية المثلى في العالم التطبيق على شبكة الإنترنت، حيث ربما الكثير من الناس يلعبون فيها. تعميم هذه الدروس لجميع السيناريوهات وعرض كل شيء كما الأظافر فقط لأننا تعلمت أن تمارس مطرقة معينة.

توصيتي ل ريتش-كلينت أبس هو استخدام الحد الأدنى من الآلية التي تلبي متطلبات كل مكون في متناول اليد. 80٪ من الوقت هذا ينبغي أن تكون الفورية الفورية. يمكن استخدام محددات الخدمة لإيواء مكونات طبقة الأعمال الرئيسية الخاصة بك (أي: خدمات التطبيقات التي هي عادة في سنغليتون في الطبيعة)، وبالطبع مصانع وحتى نمط سينغلتون أيضا مكانها. لا يوجد شيء ليقول لا يمكنك استخدام إطار دي مخبأة وراء محدد الخدمة الخاصة بك لخلق تبعيات طبقة عملك وكل ما يعتمدون على دفعة واحدة - إذا كان هذا ينتهي جعل حياتك أسهل في تلك الطبقة، ر يحمل التحميل كسول التي طبقات العرض الغنية العميل بأغلبية ساحقة . فقط تأكد من حماية رمز المستخدم الخاص بك من الوصول إلى تلك الحاوية بحيث يمكنك منع الفوضى التي تمر حاوية دي حول يمكن إنشاء.

ماذا عن قابلية الاختبار؟

ويمكن تحقيق االختبار على اإلطالق بدون إطار عمل لشركة دي. أوصي باستخدام إطار اعتراض مثل ونيتبوكس (مجانا) أو تيديبوك (الثمن). هذه الأطر تعطيك الأدوات التي تحتاجها للتغلب على المشكلة في متناول اليد (كيف يمكنك سخرية إنثياتيون والمكالمات الثابتة في C #) ولا تتطلب منك تغيير العمارة كلها للالتفاف حولها (والتي للأسف هو حيث يكون الاتجاه ذهب في العالم. نيت / جافا). فمن الحكمة لإيجاد حل للمشكلة في متناول اليد واستخدام آليات اللغة الطبيعية وأنماط الأمثل للمكون الأساسي ثم محاولة لتناسب كل ربط مربع في حفرة دي جولة. بمجرد البدء في استخدام هذه الآليات أكثر بساطة وأكثر تحديدا ستلاحظ أن هناك حاجة قليلة جدا لشركة دي في كودباس الخاص بك إذا كان أي على الإطلاق.

ملاحظة: لأبنية مففم

في البنى الأساسية مففم عرض نماذج تأخذ على نحو فعال على مسؤولية وحدات التحكم، وذلك لجميع الأغراض النظر في صيغة "تحكم" أعلاه لتطبيق "عرض نموذج". الأساسية مففم يعمل بشكل جيد لتطبيقات صغيرة ولكن كما تعقيد التطبيق ينمو قد ترغب في استخدام نهج مفكفم. تصبح نماذج العرض في الغالب دتوس البكم لتسهيل البيانات ملزمة للعرض بينما التفاعل مع طبقة الأعمال وبين مجموعات من نماذج عرض تمثل شاشات / شاشات فرعية يحصل مغلفة في مكونات تحكم / تحكم الفرعية صريحة. في أي من العمارة تقع مسؤولية المراقبين وتظهر نفس الخصائص التي نوقشت أعلاه.

Question

وسوف يكون المكونات التالية في طلبي

  • الدخول الى البيانات
  • DataAccess.Test
  • اعمال
  • Business.Test
  • الوضعية

كنت آمل أن استخدام قلعة وندسور كما يوك لغراء طبقات معا ولكن أنا غير مؤكد بعض الشيء حول تصميم الإلتصاق.

سؤالي هو من يجب أن يكون مسؤولا عن تسجيل الأشياء في وندسور؟ لدي فكرتين؛

  1. كل طبقة يمكن تسجيل الأشياء الخاصة بها. لاختبار بل، يمكن للاختبار مقاعد البدلاء تسجيل الطبقات وهمية ل دال.
  2. ويمكن لكل طبقة أن تسجل الكائن من تبعياتها، على سبيل المثال، تسجل طبقة الأعمال مكونات طبقة النفاذ إلى البيانات. لاختبار بل، فإن مقاعد البدلاء اختبار تضطر إلى تفريغ كائن دال "الحقيقي" وتسجيل الكائنات وهمية.
  3. التطبيق (أو اختبار التطبيق) يسجل جميع الكائنات من التبعيات.

هل يمكن أن يساعدني شخص ما مع بعض الأفكار والإيجابيات / سلبيات مع مختلف المسارات؟ الروابط على سبيل المثال المشاريع باستخدام قلعة وندسور بهذه الطريقة سيكون مفيدا جدا.