الحفاظ على كل شيء إلى جانب القابل للتمديد بشكل فضفاض: الكثير من الطبقات، وعلى أساس صغير جدا؟

Question

أنا (الآن أكثر من أي وقت مضى) انظر المطورين يكتبون كميات هائلة من الطبقات مثل:

implementation PresentationLayer ->
    interface IMyDTO ->
        implementation MyDTO ->
            interface IMyService -> 
                implementation MyService -> 
                    interface IMyDomainRepository ->
                        implementation MyDomainRepository ->
                            interface IMyDomainObject -> 
                                implementation MyDomainObject ->
                                    interface IMyIndependentStorageLayer ->
                                        implementation MyMSSQLStorageLayer

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

لا تفهموني خطأ، وأنا أحب الفكرة، ولكن ليس المقاضات في الوقت المناسب، خاصة في مشروع أكبر؟ هو ROI في الصيانة كبيرة حقا بما يكفي لتبرير هذا؟

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

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

Answer 1

من الصعب للغاية تصميم تصور محاذاة الأعمال المناسبة للحصول على برنامج. أعني مع رواية مقبولة.

ومع ذلك، بالنسبة لي، فإن عدد الطبقات أو مستوى الاقتران المنخفض لمفهوم البرامج يعتمد على السياق الذي سيتم فيه استخدام البرنامج!

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

Answer 2

من الواضح أنه قد يكون مبالغا فيه، ويحتاج المرء إلى معرفة "حيث تتوقف" إضافة طبقات.

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

Answer 3

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

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

Answer 4

عند تقييم هذه الأشياء، عادة ما أجدها مفيدة للنظر إليها من خلال عدسة المبدأ الجاف والنظر في ازدواجية في مشروعك.

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

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

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

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

Answer 5

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

كيف سنسحب ذلك دون فصل طبقة SQL من طبقة العمل؟

Answer 6

إنه اتجاه حديثة، وأدوات مهندسية أقل خبرة تسقط فريسة للقفز على عربة.

في المشروع، ذهبت الوصول إلى البيانات:

واجهة الخدمة -> تنفيذ الخدمة -> واجهة المندوب -> تنفيذ المندوب -> واجهة DAO -> تنفيذ DAO -> Ibatis XML.

كان هذا (وهو!) سيئة في قضيتنا، لأن معظم الكود في أي طريقة تنفيذ مندوب كان خط واحد؛ انها دعا فقط dao. لكل DAO، كان لدينا فصلين إضافيين وتكوين فاصوليا إضافيا، ونحن لن نكتسب أي شيء على الإطلاق من هذا.

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

Answer 7

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

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

هتافات