منطق الأعمال:قاعدة بيانات أو تطبيق طبقة
https://stackoverflow.com/questions/119540
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
سؤال العصر القديم.أين يجب وضع منطق تسلسل العمل الخاص بك في قاعدة بيانات الإجراءات المخزنة ( أو مجموعات ) ، أو في التطبيق/الطبقة الوسطى?والأهم من ذلك لماذا ؟
نفترض قاعدة بيانات الاستقلال ليس هدفا.
المحلول
وضع ما يكفي من منطق الأعمال في قاعدة البيانات لضمان أن البيانات متسقة الصحيح.
ولكن لا خوف الحاجة إلى تكرار بعض من هذا المنطق في مستوى آخر لتعزيز تجربة المستخدم.
نصائح أخرى
الصيانة من التعليمات البرمجية الخاصة بك هو دائما مصدر قلق كبير عند تحديد أين منطق الأعمال يجب أن تذهب.
أدوات التصحيح المتكاملة وأكثر قوة ايديس عموما تجعل الحفاظ على الطبقة الوسطى رمز أسهل من نفس التعليمات البرمجية في الإجراء المخزن.ما لم يكن هناك سبب حقيقي خلاف ذلك ، يجب أن تبدأ مع منطق الأعمال في الطبقة الوسطى/التطبيق وليس في الإجراءات المخزنة.
ولكن عندما تأتي إلى التقارير والبيانات التعدين/البحث, الإجراءات المخزنة يمكن في كثير من الأحيان خيارا أفضل.هذا هو بفضل قوة من قواعد البيانات تجميع/قدرات التصفية و حقيقة كنت حفظ معالجة قريبة جدا من مصدر البيانات.ولكن هذا قد لا يكون أكثر ما في النظر في الأعمال الكلاسيكية المنطق على أي حال.
جدا بسيطة الحالات يمكنك وضع الأعمال التجارية الخاصة بك المنطق في الإجراءات المخزنة.عادة حتى في الحالات البسيطة تميل إلى الحصول على تعقيدا مع مرور الوقت.هنا هي الأسباب لا تضع الأعمال المنطق في قاعدة البيانات:
وضع منطق الأعمال في قاعدة البيانات بإحكام الأزواج إلى التقنية تنفيذ قاعدة البيانات.تغيير الجدول سوف يؤدي إلى تغيير الكثير من الإجراءات المخزنة مرة أخرى مما تسبب في الكثير من اضافية البق اختبار إضافي.
عادة واجهة المستخدم يعتمد على منطق الأعمال لأشياء مثل التحقق من الصحة.وضع هذه الأشياء في قاعدة البيانات سوف يسبب ضيق اقتران بين قاعدة البيانات واجهة المستخدم أو في حالات مختلفة التكرارات التحقق المنطق بين هذين.
وسوف تحصل من الصعب أن يكون لديك تطبيقات متعددة تعمل على نفس قاعدة البيانات.التغييرات واحد aplication سوف يسبب الآخرين لكسر.هذا يمكن أن تتحول بسرعة إلى صيانة كابوس.لذلك لا حقا نطاق واسع.
أكثر عمليا SQL ليست لغة جيدة لتنفيذ الأعمال المنطق بطريقة مفهومة.SQL كبيرة وضعت على أساس العمليات لكنه يفتقد يبني على "البرمجة في كبير" من الصعب الحفاظ على كميات كبيرة من الإجراءات المخزنة.الحديث OO لغات هي أكثر ملاءمة وأكثر مرونة من أجل هذا.
هذا لا يعني لا يمكنك استخدام المخزنة procs وجهات النظر.أعتقد أنه في بعض الأحيان هو فكرة جيدة لوضع طبقة إضافية من الإجراءات المخزنة وجهات النظر بين الجداول و التطبيق(ق) إلى فصل اثنين.بهذه الطريقة يمكنك تغيير تخطيط قاعدة البيانات دون تغيير الواجهة الخارجية مما يسمح لك ريفاكتور قاعدة البيانات بشكل مستقل.
انها حقا متروك لكم ، طالما أنت ثابت.
سبب واحد جيد في طبقة قاعدة البيانات:إذا كنت متأكدة من أن العملاء سوف أبدا من أي وقت مضى تغيير قاعدة البيانات ذات النهاية الخلفية.
سبب واحد جيد لوضعها في طبقة التطبيق:إذا كنت تستهدف متعددة استمرار تقنيات التطبيق الخاص بك.
يجب عليك أيضا أن تأخذ بعين الاعتبار الكفاءات الأساسية.هي المطورين أساسا طبقة التطبيقات للمطورين ، أو هم في المقام الأول DBA-أنواع ؟
في حين أن هناك بالتأكيد فوائد أن يكون منطق الأعمال على طبقة التطبيقات ، أود أن أشير إلى أن اللغات/أطر يبدو أن تغيير أكثر في كثير من الأحيان ثم قواعد البيانات.
بعض الأنظمة التي لا تدعم ذهبت من خلال ما يلي معهد اليونسكو للإحصاء في 10-15 سنة الماضية:Oracle Forms/Visual Basic/Perl CGI/ ASP/Java Servlet.الشيء الوحيد الذي لم يتغير - قاعدة بيانات علائقية و الإجراءات المخزنة.
في حين لا يوجد إجابة واحدة - هذا يعتمد على المشروع في السؤال, أود أن أوصي النهج الذي دعا إليه "المجال يحركها التصميمن" من قبل اريك إيفانز.في هذا النهج منطق الأعمال معزولة في طبقة طبقة المجال - الذي يجلس على قمة طبقة البنية التحتية(s) - التي يمكن أن تشمل قاعدة البيانات رمز أدناه طبقة التطبيقات التي ترسل الطلبات إلى المجال طبقة الوفاء و يستمع تأكيد استكمال بفعالية القيادة التطبيق.
هذه الطريقة ، منطق الأعمال يتم التقاطها في نموذج التي يمكن مناقشتها مع أولئك الذين يفهمون الأعمال جانبا من المسائل التقنية ، وأنه ينبغي أن تجعل من الأسهل إلى عزل تغييرات في قواعد العمل أنفسهم ، التقنية تنفيذ القضايا, تدفق التطبيق الذي يتفاعل مع الأعمال (المجال) نموذج.
أوصي قراءة الكتاب المذكور أعلاه إذا كنت تحصل على فرصة كما هو جيد جدا في شرح كيفية هذا النقي المثالي يمكن أن يكون في الواقع يقترب في العالم الحقيقي من رمز حقيقي والمشاريع.
قاعدة بيانات الاستقلال التي السائل يستبعد في هذه الحالة ، هو أقوى حجة على أخذ المنطق من قاعدة البيانات.أقوى حجة على قاعدة الاستقلال هو القدرة على بيع البرمجيات للشركات الخاصة بهم مع تفضيل قاعدة بيانات الواجهة الخلفية.
ولذلك أعتبر أن الحجة الرئيسية لاتخاذ الإجراءات المخزنة من قاعدة البيانات تجاري واحد فقط ، وليس تقنية واحدة.قد تكون هناك أسباب فنية ولكن هناك أيضا أسباب فنية على إبقائها هناك الأداء والنزاهة والقدرة على السماح تطبيقات متعددة استخدام نفس API على سبيل المثال.
أو عدم استخدام SP هو أيضا يتأثر بقوة قاعدة البيانات التي كنت تنوي استخدامها.إذا كنت تأخذ قاعدة بيانات الاستقلال من النظر ثم عليك تجارب مختلفة جدا باستخدام T-SQL أو باستخدام PL/SQL.
إذا كنت تستخدم Oracle لتطوير تطبيق ثم PL/SQL هو خيار واضح كلغة.إنه بإحكام جدا إلى جانب البيانات تتحسن باستمرار في كل relase ، أي لائقة تطوير الأداة سوف integratePL/SQL التنمية مع السير الذاتية أو التخريب أو somesuch.
أوراكل التطبيقات المستندة إلى ويب التعبير عن بيئة التطوير حتى بنيت 100% مع PL/SQL.
أي شيء يؤثر على سلامة البيانات يجب أن تكون في مستوى قاعدة البيانات.أشياء أخرى إلى جانب واجهة المستخدم في كثير من الأحيان وضع البيانات في تحديث أو حذف البيانات من قاعدة البيانات بما في ذلك الواردات كتلة التحديثات إلى تغيير نظام التسعير, الإصلاحات, الخ.إذا كنت بحاجة للتأكد من القواعد دائما اتباعها ، ووضع المنطق في التخلف و المشغلات.
هذا لا يعني أنها ليست فكرة جيدة أن يكون أيضا في واجهة المستخدم (لماذا تهتم بإرسال معلومات قاعدة البيانات لن تقبل), ولكن تجاهل هذه الأشياء في قاعدة البيانات إلى المحكمة الكوارث.
إذا كنت بحاجة إلى قاعدة بيانات الاستقلال عليك ربما تريد أن تضع كل منطق الأعمال في طبقة التطبيق منذ المعايير المتاحة في تطبيق الطبقة هي الآن أكثر انتشارا من تلك المتاحة في قاعدة بيانات الطبقة.
ومع ذلك ، إذا كانت قاعدة البيانات الاستقلال ليس #1 عامل المهارة مجموعة من فريق العمل الخاص بك يتضمن بيانات قوية من المهارات ، ثم وضع منطق الأعمال في قاعدة البيانات قد يكون أفضل حل.هل يمكن أن يكون التطبيق الخاص بك الناس القيام بالتطبيق الأشياء قاعدة البيانات الخاصة بك الناس التأكد من جميع استفسارات يطير.
بالطبع هناك فرق كبير بين أن تكون قادرة على رمي SQL معا وجود "بيانات قوية المهارات" - إذا كان الفريق الخاص بك هو أقرب إلى سابق من هذا الأخير ثم وضع المنطق في التطبيق باستخدام واحدة من إسبات من هذا العالم (أو تغيير فريق العمل الخاص بك!).
في تجربتي, في بيئة مؤسسة سيكون لديك هدف واحد في قاعدة البيانات والمهارات في هذا المجال - في هذه الحالة وضع كل شيء في قاعدة البيانات الخاصة بنا.إذا كنت في الأعمال التجارية من بيع البرمجيات قاعدة البيانات تكاليف الترخيص سوف تجعل قاعدة البيانات الاستقلال أكبر عامل وسوف يتم تنفيذ كل ما يمكنك في تطبيق الطبقة.
على أمل أن يساعد.
هو في الوقت الحاضر يمكن أن يقدم على التخريب المخزنة proc رمز إلى تصحيح هذا الكود مع أداة جيدة الدعم.
إذا كنت تستخدم المخزنة procs أن الجمع بين البيانات sql يمكنك تقليل كمية مرور البيانات بين التطبيق وقاعدة البيانات و تقليل عدد المكالمات قاعدة بيانات والحصول على الأداء الكبير المكاسب.
عندما بدأنا بناء في C# اتخذنا قرار عدم استخدام المخزنة procs ولكن الآن نحن نتحرك أكثر وأكثر رمز المخزنة procs.وخاصة تجهيز الدفعات.
ومع ذلك لا تستخدم المشغلات, استخدام المخزنة procs أو أفضل حزم.مشغلات هل انخفاض الصيانة.
وضع التعليمات البرمجية في التطبيق طبقة سيؤدي في DB تطبيق مستقل.
في بعض الأحيان أنه من الأفضل استخدام الإجراءات المخزنة لأسباب تتعلق بالأداء.
فإنه (كالعادة) يعتمد على متطلبات التطبيق.
الشيء الوحيد الذي يذهب في قاعدة البيانات.
الإجراءات المخزنة صيانة كابوس.فهي ليست البيانات وأنها لا تنتمي في قاعدة البيانات.التي لا نهاية لها التنسيق بين المطورين و DBA هو أكثر قليلا من التنظيمية الاحتكاك.
فإنه من الصعب للحفاظ على نسخة جيدة من السيطرة على الإجراءات المخزنة.رمز خارج قاعدة البيانات من السهل حقا لتثبيت -- عندما كنت تعتقد أنك قد حصلت على إصدار خاطئ فقط لا SVN حتى (ربما تثبيت) التطبيق الخاص بك مرة أخرى إلى الدولة المعروفة.لديك متغيرات البيئة, دليل روابط, والكثير من بيئة الرقابة على تطبيق.
يمكنك مع بسيطة PATH التلاعب ، يكون البديل البرمجيات المتاحة لحالات مختلفة (التدريب, اختبار, ضمان الجودة, الإنتاج, خاصة بالعميل التحسينات ، وما إلى ذلك ، .... الخ)
التعليمات البرمجية داخل قاعدة البيانات ، ومع ذلك ، من الصعب إدارتها.لا يوجد البيئة المناسبة -- لا "المسار" ، دليل وصلات أو غيرها من متغيرات البيئة -- تقديم أي صالحة للاستعمال السيطرة على ما البرامج المستخدمة ؛ لديك الدائم على الصعيد العالمي لا بد من تطبيق البرمجيات عالقة في قاعدة البيانات ، متزوج من البيانات.
المشغلات هي أسوأ من ذلك.كلاهما الصيانة و التصحيح كابوس.أنا لا أرى ما المشكلة التي حل ؛ يبدو أنها ستكون طريقة العمل حول مصممة بشكل سيئ التطبيقات حيث شخص لا يمكن أن تكون ازعجت استخدام الطبقات المتاحة (أو وظيفة المكتبات) بشكل صحيح.
في حين أن بعض الناس تجد أداء حجة مقنعة, ما زلت لم أر ما يكفي من البيانات المرجعية إقناعي أن الإجراءات المخزنة كل ذلك بسرعة.كل شخص لديه حكاية, ولكن لا أحد لديه جنبا إلى جنب البرمجية حيث الخوارزميات هي أكثر أو أقل نفس.
[في الأمثلة التي رأيتها ، وتطبيق القديم كان سوء تصميم الفوضى.عندما الإجراءات المخزنة كتابة التطبيق تم إعادة هندستها.أعتقد أن تغيير تصميم تأثير أكثر من منصة التغيير.]
منطق الأعمال ينبغي أن توضع في تطبيق الطبقة الوسطى باعتبارها الخيار الأول.وبهذه الطريقة فإنه يمكن التعبير عنها في شكل نموذج المجال ، وضعها في المصدر السيطرة ، يتم تقسيم أو جنبا إلى جنب مع التعليمات البرمجية ذات الصلة (بتعميل الترميز) ، الخ.كما أنه يتيح لك بعض بيانات البائع الاستقلال.
وجوه المنحى لغة هي أيضا الكثير أكثر تعبيرا من الإجراءات المخزنة مما يتيح لك أفضل وأكثر سهولة وصف في قانون ما يجب أن يحدث.
فقط أسباب جيدة لوضع الكود في الإجراءات المخزنة هي:إذا كان القيام بذلك ينتج هامة وضرورية الأداء فائدة أو إذا كان نفس العمل من أجل تنفيذها من خلال منصات متعددة (Java, C#, PHP).حتى عند استخدام منصات متعددة ، هناك بدائل مثل خدمات الويب التي قد تكون أكثر ملاءمة تقاسم الوظائف.
الجواب في تجربتي يكمن في مكان ما على مجموعة من القيم التي تحدد عادة من قبل حيث مؤسستك مهارات الكذب.
قاعدة البيانات هي قوية جدا الوحش ، مما يعني السليم أو معاملة غير لائقة سوف تجلب فائدة كبيرة أو عظيم الخطر.للأسف في الكثير من المنظمات الرئيسية اهتمام البرمجة الموظفين ؛ dbms مهارات خاصة الاستعلام تنمية المهارات (بدلا الإدارية) مهملة.والتي تفاقمت بسبب حقيقة أن القدرة على تقييم dbms المهارات هي أيضا ربما في عداد المفقودين.
وهناك عدد قليل من المبرمجين الذين كاف يفهم ما لا يفهمون عن قواعد البيانات.
وبالتالي شعبية الأمثل المفاهيم مثل السجلات النشطة و ينق (رمي في بعض تحيز واضح).ولكن ربما أفضل إجابة لمثل هذه المنظمات.
ومع ذلك, علما بأن للغاية تحجيم المنظمات تميل إلى دفع الكثير من الاهتمام فعالية استخدام مخزن البيانات.
لا يوجد مستقل الإجابة الصحيحة على هذا السؤال.ذلك يعتمد على متطلبات التطبيق الخاص بك ، تفضيلات مهارات المطورين و مرحلة القمر.
منطق الأعمال هو أن تكون وضعت في التطبيق من الدرجة وليس في قاعدة البيانات.والسبب هو أن قاعدة البيانات الإجراء المخزن دائما dependen على قاعدة البيانات يمكنك استخدام المنتج.هذا كسر واحدة من المزايا من ثلاث طبقات نموذج.لا يمكنك تغيير بسهولة إلى قاعدة بيانات أخرى إلا إذا توفر إضافية الإجراء المخزن لهذا بيانات المنتج.من ناحية أخرى في بعض الأحيان ، فمن المنطقي أن وضع المنطق إلى الإجراء المخزن للحصول على الأداء الأمثل.
ما أريد أن أقوله هو منطق الأعمال هو أن تكون وضعت في تطبيق الطبقة, ولكن هناك استثناءات (أساسا أسباب الأداء)
Bussiness تطبيق الطبقات هي:
1.واجهة المستخدم
هذا وتنفذ الأعمال-عرض المستخدم من ساعة(هو/ايه) وظيفة.ويستخدم حيث أن المستخدم هو مألوف مع.
2.تجهيز
هذا هو المكان العمليات الحسابية و معالجة البيانات يحدث.أي منطق الأعمال التي تنطوي على تغيير البيانات يتم تنفيذها هنا.
3.قاعدة البيانات
هذا يمكن أن يكون:وتطبيع متتابعة قاعدة البيانات (القياسية المستندة إلى SQL DBMS) ؛ وهو OO-قاعدة بيانات لتخزين الكائنات التفاف الأعمال-البيانات ؛ الخ.
ما يجري فيها
في الحصول على فوق طبقات تحتاج إلى القيام الضروري تحليل و تصميم.هذا من شأنه أن يشير إلى أين منطق الأعمال أفضل تنفيذها:البيانات-قواعد التكامل والتزامن/في الوقت الحقيقي المسائل المتعلقة البيانات التحديثات عادة ما يتم تنفيذها على مقربة من البيانات, كما أن الحقول المحسوبة ، وهذا مؤشر جيد إلى تخزين الإجراءات/المشغلات ، حيث البيانات وسلامة المعاملات-التحكم ضروري.
الأعمال-القواعد التي تنطوي على معنى واستخدام البيانات أن معظم تنفذ في تجهيز طبقة ، ولكن أيضا تظهر في واجهة المستخدم باسم المستخدم تدفق العمل - ربط عملية مختلفة في بعض تسلسل يعكس المستخدم الوظيفي.
Imho.هناك نوعان من المخاوف متضاربة مع البت فيها منطق الأعمال يذهب في قاعدة بيانات علائقية يحركها التطبيق:
- الصيانة
- الموثوقية
Re.الصيانة:للسماح كفاءة التنمية في المستقبل ، منطق الأعمال ينتمي في جزء من التطبيق الخاص بك هذا هو أسهل التصحيح و التحكم في الإصدار.
Re.الموثوقية:عندما يكون هناك خطر كبير من التناقض ، منطق الأعمال ينتمي إلى طبقة قاعدة البيانات.قواعد البيانات العلائقية يمكن أن تكون مصممة للتحقق من القيود على البيانات, على سبيل المثاللا يسمح قيم فارغة في أعمدة معينة ، الخ.عندما السيناريو الذي يطرح نفسه في تصميم التطبيق حيث أن بعض البيانات يجب أن تكون في دولة معينة التي هي معقدة للغاية عن هذه القيود يمكن أن يعقل أن استخدام الزناد أو شيئا من هذا القبيل في طبقة قاعدة البيانات.
مشغلات الألم للحفاظ على ما يصل إلى التاريخ ، وخاصة عند التطبيق الخاص بك من المفترض أن تعمل على أنظمة العميل لم يكن لديك حتى الوصول للغاية.ولكن هذا لا يعني أنه من المستحيل أن تتبع لهم أو تحديثها.S. لوت حجج في جوابه أنه من آلام ومتاعب هي صالحة تماما, سوف الثانية أن يكون هناك أيضا.ولكن اذا واصلتم هذه القيود في الاعتبار عند أول تصميم طبقة البيانات و الامتناع عن استخدام مشغلات ووظائف أي شيء ولكن الضرورات المطلقة انها يمكن التحكم فيها.
في التطبيق لدينا ، معظم الأعمال المنطق هو الوارد في تطبيق نموذج طبقة مثلفاتورة يعرف كيفية تهيئة نفسه من أمر المبيعات.عندما مجموعة من الأشياء المختلفة يتم تعديل بالتتابع على مجموعة معقدة من التغييرات مثل هذا نطويهم في المعاملات للحفاظ على الاتساق ، وبدلا من اختيار الإجراء المخزن.حساب المجاميع الخ.يتم كل ذلك مع أساليب في نموذج طبقة.ولكن عندما نحتاج إلى denormalize شيء عن الأداء أو إدراج البيانات في "تغييرات" الجدول استخدامها من قبل جميع العملاء لمعرفة أي من الأشياء التي تحتاج أن تنتهي في الدورة ذاكرة التخزين المؤقت ، ونحن استخدام المشغلات/وظائف في طبقة قاعدة البيانات إلى إدراج صف جديد وترسل إشعارا (بوستجرس الاستماع/يخطر الاشياء) من هذا المشغل.
بعد أن التطبيق لدينا في هذا المجال لمدة سنة ، وتستخدم من قبل مئات من العملاء كل يوم ، الشيء الوحيد الذي أود أن التغيير إذا كان لنا أن نبدأ من الصفر سيكون تصميم النظام من أجل إنشاء قاعدة بيانات الوظائف (أو الإجراءات المخزنة ، ومع ذلك تريد أن تسميها) مع الإصدارات والتحديثات لهم في العقل من الحصول على الذهاب.
لحسن الحظ لدينا بعض نظام لتتبع المخطط الإصدارات ، لذا قمنا ببناء شيء على أعلى من ذلك أن تأخذ الرعاية من استبدال وظائف قاعدة البيانات.لقد حفظ لنا بعض الوقت الآن لو نظرت تحتاج إلى استبدالها من البداية على الرغم من.
بالطبع, كل شيء يتغير عندما كنت خطوة خارج عالم RDBMS في tuple-أنظمة التخزين مثل الأمازون SimpleDB و جوجل BigTable.ولكن هذا هو قصة مختلفة :)
وضعنا الكثير من الأعمال المنطق في الإجراءات المخزنة - انها ليست مثالية, ولكن في كثير من الأحيان أنها جيدة التوازن بين الأداء والموثوقية.
ونحن نعرف أين هو دون الحاجة إلى البحث من خلال فدان من الحلول codebase!
قابلية هو أيضا عامل مهم جدا بالنسبة pusing منطق الأعمال في منتصف أو التطبيق طبقة من طبقة قاعدة البيانات.ينبغي أن يكون مفهوما أن DatabaseLayer هو فقط من أجل التفاعل مع قاعدة البيانات لا التلاعب الذي عاد إلى أو من قاعدة البيانات.
أذكر أني قرأت مقالا في مكان ما أن أشار إلى أن جيد كل شيء يمكن أن يكون في مستوى جزء من منطق الأعمال ، لذا فإن السؤال لا معنى له.
أعتقد أن المثال المذكور كان عرض الفاتورة على الشاشة.قرار مارك تأخير في الأحمر هو قرار تجاري...
إنها سلسلة متصلة.IMHO أكبر عامل السرعة.كيف u هذا اللعين وتشغيلها في أسرع وقت ممكن في حين لا يزال التمسك المستأجرين جيدة البرمجة مثل الصيانة الأداء وقابلية التوسع والأمن والاعتمادية.... الخفي كثير من الأحيان SQL هو الأكثر إيجازا طريقة للتعبير عن شيء ما و يحدث أيضا أن تكون أكثر performant مرات عديدة ، باستثناء سلسلة عمليات إلخ ، ولكن من أين CLR Procs يمكن أن تساعد.اعتقادي هو أن رش تحرري منطق الأعمال حول أينما كنت أشعر أنه هو الأفضل لهذه المهمة في متناول اليد.إذا كان لديك مجموعة من مطوري التطبيقات الذين القرف سراويلهم عند النظر في SQL ثم السماح لهم استخدام التطبيق المنطق.إذا كنت تريد حقا لخلق عالية الأداء التطبيق مع مجموعات كبيرة من البيانات ، ووضع الكثير من المنطق في DB كما يمكنك.إطلاق النار الخاص بك DBA و تعطي المطورين الحرية المطلقة على ديف قواعد البيانات.لا توجد إجابة واحدة أو أفضل وسيلة للحصول على الوظيفة.لديك العديد من الأدوات بحيث تصبح خبير في جميع مستويات التطبيق وسوف تجد قريبا أن كنت تنفق الكثير من الوقت في كتابة لطيفة consise معبرة SQL حيث هناك ما يبرر استخدام طبقة التطبيق مرة أخرى.لي في نهاية المطاف ، والحد من عدد من الأسطر من التعليمات البرمجية هو ما يؤدي إلى البساطة.لدينا فقط تحويل sql تطبيق الغنية مع مجرد 2500 خطوط من رمز التطبيق و 1000 خطوط SQL إلى نموذج المجال والتي لديها الآن 15500 خطوط من رمز التطبيق و 2500 خطوط SQL لتحقيق السابق sql الغنية التطبيق.إذا كنت يمكن أن يبرر 6 أضعاف الزيادة في مدونة باسم "المبسطة" ثم الذهاب الحق المقبلة.
هذا هو السؤال الكبير!لقد وجدت هذا بعد أن كنت قد سألت مشابهه السؤال, ولكن هذا هو أكثر تحديدا.جاء نتيجة تغيير تصميم المقرر التي لم تشارك في صنع.
أساسا ما قيل أنه إذا كان لديك الملايين من صفوف من البيانات في جداول قاعدة البيانات الخاصة بك ، ثم ننظر في وضع منطق الأعمال في الإجراءات المخزنة والمشغلات.هذا هو ما نقوم به الآن, تحويل جافا التطبيق في الإجراءات المخزنة الصيانة كما كود جافا أصبحت معقدة.
لقد وجدت هذه المادة على: منطق الأعمال الحروب المؤلف أيضا في جعل مليون الصفوف في جدول الحجة التي وجدت للاهتمام.وأضاف منطق الأعمال في جافا سكريبت ، وهو جانب العميل و خارج منطق الأعمال الطبقة.لم أفكر في هذا من قبل حتى وإن كنت تستخدم جافا سكريبت التحقق من صحة سنوات ، جنبا إلى جنب مع التحقق من جانب الخادم.
رأيي هو أنك تريد منطق الأعمال في التطبيق/الطبقة الوسطى وكقاعدة عامة من الإبهام, ولكن لا خصم الحالات حيث أنه من المنطقي لوضعها في قاعدة البيانات.
نقطة أخيرة, هناك مجموعة أخرى حيث أعمل حاليا أن يفعل بيانات ضخمة العمل للبحث و كمية البيانات التي يتم التعامل معها هي هائلة.لا يزال بالنسبة لهم ليس لديهم أي منطق الأعمال في قاعدة البيانات نفسها ، ولكن يبقيه في التطبيق/الطبقة الوسطى.التصميم التطبيق/الطبقة الوسطى كان المكان الصحيح ، حتى لا تستخدم حجم الجداول فقط النظر في التصميم.
منطق الأعمال عادة ما يتجسد في الأشياء و مختلف بنيات اللغة من والميراث ، وتعدد الأشكال.على سبيل المثال ، إذا كان تطبيق المصرفية يمر حول المال ، قد يكون هناك نوع المال الذي يحدد الأعمال من عناصر ما "المال" هو.هذا بدلا من استخدام البدائية عشري لتمثيل المال.لهذا السبب, مصممة بشكل جيد OOP حيث "منطق الأعمال" حياة ليس بدقة في أي طبقة.
