تطبيقات متعددة المستويات مع PHP؟

Question

أنا جديد نسبيًا على PHP ، لكنني عانيت من مبرمج Java في بيئات المؤسسات المعقدة مع هندسة الخدمية والتطبيقات المتعددة. هناك ، سنقوم عادة بتنفيذ تطبيقات الأعمال مع منطق الأعمال على الطبقة الوسطى.

أقوم ببرمجة نظام عملة بديل ، والذي يجب أن يكون سهل النشر وقابل للتخصيص من قبل الأفراد والمجتمعات ؛ سيكون مفتوح المصدر. لهذا السبب يبدو أن PHP/MySQL هو الخيار الأفضل بالنسبة لي.

لدى المستخدمين حسابات ، ويحصلون على توازن. أيضا ، يحسب النظام الأسعار اعتمادًا على إجمالي الخدمات المقدمة وإجمالي الأصول المتاحة.

هذا يعني ، عند شراء سلسلة من الحسابات تحدث ؛ يتم تحديث التوازن والإجماليات ؛ هذه أرقام مشتقة ، شيء لا يتم وضعه عادة في قاعدة بيانات.

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

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

آمل أن أكون قد أوضحت سؤالي. كل التعليقات موضع تقدير. قد لا يكون هناك حل "مثالي".

Answer 1

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

في مشكلة المشغلات ، لست متأكدًا مما إذا كان ذلك ضروريًا لتطبيقك. نظرًا لأن المستخدم يتم استدعاء الأحداث التي تثير الحسابات من قبل المستخدم ، يمكن أن تحدث هذه الأشياء في PHP ، حتى لو تم إعادة توجيه المستخدم إلى صفحة "انتظار" أو صفحة أخرى في هذه الأثناء. من الواضح أنه لا يمكن القيام بالمشغلات الحقيقية إلا على مستوى DB ، ولكن يمكنك استخدام خيط Daemon الذي يدير برنامج نصي PHP في كل ثوانٍ ... تجنب ذلك بأي ثمن ومحاولة الحصول على الحدث من جانب المستخدم.

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

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

Answer 2

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

Answer 3

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

ومع ذلك ، أنا متأكد من أنه لكل مطور هنا يتفق معك (وأنا) ، هناك على الأقل العديد من الذين يعتقدون العكس تمامًا وكان لديهم تجارب جيدة في القيام بذلك.

Answer 4

شكرا يا رفاق.

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

الآن ، أرى أن هناك حلًا لنشر رمز PHP على مستويات متعددة ، ليس من المنطقي فقط ولكن أيضًا جسديًا عن طريق النشر على خوادم مختلفة.

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

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

من ناحية أخرى ، بالطبع ، أوافق على أن أشياء DB قد تصعب تصحيحها.

نصوص DB init في التحكم في المصدر ، وكذلك ملفات PHP :)

شكرًا لك مرة أخرى