سؤال

أنا تدقيق مشروع يستخدم ما يسمى قواعد المحرك.باختصار, انها طريقة تخريج منطق الأعمال من رمز التطبيق.

هذا المفهوم هو جديد تماما بالنسبة لي و أنا متشككة جدا حول هذا الموضوع.بعد سماع الناس يتحدثون عن فقر الدم المجال نماذج على مدى السنوات القليلة الماضية, أنا التشكيك في قواعد المحرك النهج.بالنسبة لي يبدو وكأنه وسيلة رائعة يضعف نموذج المجال.على سبيل المثال يقول أنا أفعل جافا webapp التفاعل مع قواعد المحرك.ثم قررت أنني أريد أن يكون التطبيق الروبوت على أساس نفس المجال.إلا إذا كنت تريد التطبيق الروبوت إلى التفاعل مع قواعد المحرك حسنا, انا ذاهب الى أن تفوت على أي منطق الأعمال مكتوبة مسبقا.

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

تحديث - منذ كتابة هذا الإله نفسه ، مارتن فاولر ، كتبت عن استخدام محرك قواعد.

هل كانت مفيدة؟

المحلول

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

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

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

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

نصائح أخرى

أعتقد أن المخاوف الخاصة بك عن فقر الدم المجال نماذج صالحة.

رأيت اثنين من التطبيقات التجارية المعروفة Rete قواعد تشغيل المحرك في الإنتاج حيث أعمل.كنت تنظر واحد النجاح وغيرها من الفشل.

التطبيق الناجح هو قرار شجرة التطبيق تتكون من ~الأشجار 10 ~30 فرع نقطة لكل منهما.قواعد المحرك لديه واجهة المستخدم التي تسمح أهل الأعمال للحفاظ على النظام.

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

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

أود أن تقلق أيضا عن محرك قواعد تصبح المفرد عنق الزجاجة في التطبيق الخاص بك.

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

القاعدة محركات يمكن أن تقدم الكثير من القيمة في حالات معينة.

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

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

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

على سبيل المثال, صريح مهتم في أوامر مع ما مجموعه أكثر من 1000 دولار ، لذلك فهو يضع في سيادة النظام الذي كان من المهتمين."إن النظام.إجمالي > 1000 ثم أرسل فرانك".

وفي الوقت نفسه, سالي يريد كل أوامر من الساحل الغربي:"إن النظام.المصدر == 'WEST_COAST' ثم أرسل سالي".

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

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

الآن, من الواضح في نظام معقد وهناك كل أنواع من العلاقات التي يمكن أن يحدث ، هذا هو السبب في النظام بأكمله ليس "فعل مع القواعد".شخص ما في مكان ما سوف يكون مسؤولا عن القواعد لا تخرج من يده.ولكن هذا لا يعني بالضرورة التقليل من قيمة هذا النظام يمكن أن توفر.

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

على أية حال, أتمنى أن يوضح هذا المثال كيف أن قواعد النظام يمكن أن تساعد في زيادة أكبر في التطبيق.

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

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

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

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

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

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

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

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

"ولكن في الحقيقة ، كيف العديد من التطبيقات حقا أن العديد من التغييرات؟"

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

الواقع هو أنه لا يمكنك التفكير في كل شيء مقدما ، وبالتالي سبب مرونة العمليات.كما BA دائما يبدو أن تفوت شيء حيوي حتى انها وجدت في الاختبار.

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

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

الكثير من إجابات جيدة بالفعل ولكن أريد أن أضيف بعض الأشياء:

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

أرى القاعدة ومعالجة البيانات محركات (أ.ك.أ.قواعد البيانات) في الأساس مماثلة.ولكن لسبب ما, ونحن لا نقول blackboxing استمرار النظام الفرعي هو سيء.

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

أكبر تعقيد من تجربتي في القاعدة محركات هو أن:

  1. من OOP بوف هو الألم الحقيقي ريفاكتور واختبار قواعد مكتوبة في اللغة التقريرية بينما يتم إعادة بيع ديون رمز التي تؤثر عليهم.
  2. في كثير من الأحيان يجب علينا دائما التفكير في أمر التنفيذ من القواعد التي تتحول إلى فوضى عندما يكون هناك الكثير منهم.
  3. بعض التغييرات الطفيفة التي قد تؤدي صحيحة سلوك القواعد مما يؤدي إلى إنتاج البق.في واقع الامر انه ليس من الممكن دائما أن تغطي جميع الحالات مع الاختبارات مقدما.
  4. قواعد تحور الأشياء المستخدمة في تلك الأخرى أيضا زيادة تعقيد مما تسبب المطورين إلى الخروج منها إلى مراحل.
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top