قد يظن العديد من المبرمجين أن العنوان غير صحيح أو مبهم، ولكن بعد قرائتي لمقال المدون تركي العسيري عن التطبيقات متعددة الطبقات وتشبيهه هذا النوع من التطبيقات كقطعة من الهامبورجر (أو كما يقال بالليبي الهامبورجا وبالأجنبي Hamburger) بها العديد من الطبقات أولها طبقتي الخبز (وهي الواجهة)، تم طبقات من السلطة والبطاطس المحمرة (وهي الطبقة الوسطى)، بينما تكون الطبقة الداخلية هي قاعدة البيانات الرئيسية (أى طبقة اللحم اللذيذ)، ولكي تصل إليها لابد من المرور بكل الطبقات وهو مايعطي لهذا النوع من التطبيقات مميزاتها وهي:
- إمكانية إضافة طبقات أكثر للجائعين، أو إنقاص عدد الطبقات أو تغييرها لأصحاب الريجيم.
- الإقلال من تعقيد طبخ الهمبورجا (بما أن الطبقات جاهزة وماعليك سوا ترتيبها).
- يمكن تحضير العديد من أنواع الهمبورجا بدون إعادة طبخها من جديد.
- مناسبة للمطابخ والمطاعم، بما أن الطبقات جاهزة للإستخدام ولا تتطلب الكثير من المجهود لتعديلها.
- إمكانية تغيير نوع الخبز(الطبقة الخارجية)، فيظن الناظر إليها أنها نوع أخر من الهامبورجر.
- في حالة وجود أعيب في إحدى الطبقات يمكن إصلاح هذا العيب بدون الحاجة لتعديل باقي الطبقات، كما يمكن تغيير الطبقة المعيبة بسهولة كذلك.
- يمكن شراء طبقة أو أكثر من طرف أخر بدون الحاجة للقيام بإعدادها محلياً.
ولكن لهذا النوع عيوبه كذلك والتي منها:
- تتطلب الإهتمام بتحضير كل طبقة بطريقة جيدة.
- يجب أن يكون هناك توثيق جيد و تنبيه باقي الطباخين لمحتويات كل طبقة لكي يتم إستخدامها الإستخدام المناسب.
- يجب أن يتم تثبيت كل طبقة بطريقة مناسبة على الطبقة الأخرى (قد يكون من غير الملائم وضع طبقات متنافرة على بعضها البعض).
- طبخ كل طبقة لوحدها لضمان جودة المذاق، وهو ما يتطلب الكثير من الجهد والوقت.
هذه كانت بعض مميزات وعيوب الهامبورجر، والتي يمكن بسهولة مطلقة تطبيقها على طريقة كتابة الكود البرمجي للمنظومات المتداولة في السوق المحلي، والتي لاحظت من خلال خبرتي القصيرة في مجال البرمجة التطابق التام فيما بينهما، وبالرغم من أنني أعمل في تطوير تطبيق متعدد الطبقات إلا أنني أميل إلى التطبيقات المسماة (Client\Server) عند قيامي بتطوير تطبيقاتي الخاصة، وبالرغم من إصرار زملائي على برمجة أنظمتهم الخاصة بتقنية متعددة التطبيقات، إلا أنني أرى أن عيوبها في مجال البرمجة (وليست التقنية بحد ذاتها) هي ما يدفعني لعدم الإهتمام بها كثيراً.
فحسب وجهة نظري التطبيقات المتعددة الطبقات تكون جيدة بل وممتازة عند تطبيقها في مشاريع كبيرة (مثل منظومة للمصارف، نظام متكامل للمستشفيات، نظام متكامل للشركات الكبيرة) ويجب أن يكون العمل ضمن فريق لايقل عن ثلاثة أفراد، وأن يكون الفريق مترابطاً ومتكاتفاً ويعمل بنفس المستوى البرمجي لضمان الترابط التام بين كل الطبقات، بالإضاة إلى أن التطبيقات التي يتم إنتاجها بهذه التقنية تكون غالية الثمن (على المستوى المحلي) وذلك لوجود العديد من التكاليف والتي منها مرتبات فريق البرمجة ومصروفات الأجهزة والمعدات والمأكل و المشرب، ثم لا ننسي أن هذا النوع من التطبيقات يحتاج إلى الصيانة والمتابعة لفترة لاتقل عن عام لإصلاح العلل البرمجية والأخطاء المنطقية، بالإضافة إلى المطاليب الخاصة بالمشتري، فتخيل لو أن أحد المبرمجين ترك الفريق أو قام بأخذ الكود البرمجي وبيعه لشخص أخر بعد إقناع الحميع بأنه كود جديد، ففي هذه الحالة سيترتب العديد من المشاكل التقنية والأدبية والتي منها عدم ثقة باقي الفريق ببعضهم البعض والحاجة الماسة للبحث عن شخص جديد يبدأ من الصفر أو توزيع الحمل البرمجي على من بقي من المبرمجين..
وإذا أردت القيام بتطوير تطبيقات شخصية أو لوحدك بإستخدام هذه التقنية فإنك ستكون مجبراً على معرفة كيفية تصميم وبرمجة قواعد البيانات (أفضلها بالنسبة إلي SQL Server 2000 أو SQL Server 2005) حيث يتم تكوين طبقة قاعدة البيانات (أو مايسمى بــ Data Layer)، ولاننسى كذلك برمجة نظام الربط مع قواعد البيانات (Data Access Layer)، ثم يجب عليك تعلم مهارات برمجة مكتبات الربط الديناميكية (Dynamic Library Link - DLL) بإستخدام إحدى لغات البرمجة الحديثة (بالنسبة إلي أفضل العمل على Visual Basic 6) وفي هذه الطبقة يتم تكوين طبقة العمل (أو مايسمى بــBusiness Logic Layer)، حيث يتم فيه تطبيق القوانين الخاصة بالتعامل مع البيانات (دوال تخزين وجلب وتعديل وإلغاء البيانات)، ويتطلب هذا المستوى التعرف السليم على أوامر دوال التنفيذ النخزنة في قاعدة البيانات (Stored Procedures) لكي يتم تحويلها من مفهوم قاعدة البيانات كجمل T-SQL وماتحمله من أوامر (Insert,update,select and delete) إلى أوامر ودوال مفهومة (مثل UpdateSalaryTable)، ويتطلب هذا الأمر زمناً الكثير من الكود البرمجي والتجارب لتفادي العلل والأخطاء البرمجية، مع ملاحظة أن أي تغغير في قاعدة البيانات من ناحية إلغاء بعض الحقول أو تغيير نوعها سيتطلب منك أن تقوم بإعادة تعديل هذا المستوى لكي يتطابق معها من جديد، ثم يأتي دور واجهة المستخدم (Presentation Layer)، وهنا يمكنك برمجتها بإستخدام العديد من الطرق والتي منها (Windows Forms, Web Forms or TabletPC Forms)، وهي الطبقة الوحيدة التي يستطيع المستخدم (Client) مشاهدتها والتعامل معها ولذلك يجب أن تكون في غاية البساطة والوضوح ويمكن من خلالها عرض المعلومات بطريقة مريحة وإدخالها بسهولة.
مما تقدم نجد أن مبرمجاً واحد لن يستطيع القيام ببرمجة كل هذه الطبقات بكفاءة، فهو إما أن يكون متمكناً من قواعد البيانات وفي هذه الحال سيتشتت ذهنه عندما يقوم بتصميم وبرمجة واجهة المستخدم أو العكس، كما أنه يتطلب منه الكثير جداً من الجهد والوقت و الذي سينتج عنه بعد مدة قناعة راسخة أن مجهوده سيباع بثمن بخس، فهو لكي يستطيع مواجهة المنظومات الموجودة في السوق سيلعب على وتر السعر، والذي سينتج عنه مشاكل عكسية في الجودة، ثم أن المستخدم النهائي لن يستطيع المقارنة بين التقنيات الموجودة أمامه بطريقة تقنية سليمة (فهو لن يقارن أكثر من واجهة الإستخدام)، وهو ماستترتب عليه أثار سيئة عند مقارنة مجموعة من المنظومات العاملة بتقنيات مختلفة.
وربما يعتقد البعض أن هذه التقنية هي أخر ماتوصلت إليه هندسة البرمجيات ويجب أن يتعلموها حتى يصبحوا عاملين على أخر ماتوصلت إليه البرمجة، ولكن هذا الكلام غير صحيح بالكامل، ولتوضيح ذلك يمكننا إلقاء نظرة على تاريخ هذه التقنية.
البرمجة متعددةالطبقات
بدأ هذا النوع من التقنية بعد إطلاق نسخة (WindowsNT) وماحمله من تقنية (Microsoft Transaction Server - MTS)، والتي تتمثل في أبسط صورها بضرورة تعامل البرامج مع طبقات وسيطة قبل وصولها إلى قاعدة البيانات لتخفيف العبأ على أجهزة المستخدمين الضعيفة (وقتها) وتركيوه على أجهزة الخادم التي تفوقها في القوة بكثير من حيث الموارد (سرعة المعاالجة، ذاكرة التخزين، توزيع الحمل)، وترابطت هذه التقنية وترسخت أكثر بعد إطلاق (Windows95) و (Windows98)، وقد روجت شركة Microsoft لهذه التقنية كثيراً، إلا أنه وعند إطلاق (Windows 2000 Family) وما تضمنه من نسخة الخادم (Windows 2000 Server) ونسخة العميل (Windows 2000 Professional) ثم إستبدال هذه التقنية بتقنية أكثر تطوراً منها بكثير وهي تقنية (+COM) والتي بشرت بالعديد من المزايا الخاصة بتقنية الطبقات المتعددة ولكنها أصرت على إعتماد نظم التشغيل الحديثة (Windows 2000 ومابعده)، ولا زالات هذه التقنية ي تطور مستمر.
لماذا؟
في البداية كان إستخدام هذه التقنية بسبب محدودية أجهزة المستخدمين وقوة أجهزة الخادم (في ذلك الوقت) ولكن هذا السبب تغيير اليوم بسبب نزول أسعار الأجهزة بطريقة كبيرة حتى أن أجهزة المستخدمين تتفوق في بعض الشركات على أجهزة الخادم، وهو ما دفع المبرمجين إلى الرجوع إلى الطرق القديمة كالبرمجة على مستوى الطبقة الواحدة (Desktop Application) أو الطبقتين (Client/Server Application) للإستفادة من قوة أجهزة المستخدمين وتخفيف العبأ على الجهاز الخادم، ما دفع البعض إلى توقع موت تقنية تعدد الطبقات، ومن التقنيات الجديدة التي برزت كفكرة لإستغلال قوة أجهزة العميل (Client PC) تقنية (Ajax) الخاصة بتطبيقات الإنترنت والإنترانت، ولعل الكثير منا شاهدها في مواقع مثل (Flickr, Yahoo, Google Mail, MSN Start) وغيرها الكثير، كما أن لغات البرمجة الحديثة (مثل Visual Studio 2005 .NET) باتت توسع من أفاق التقنيات التي يمكن للمبرمج إختيارها بدون التحيز لتقنية واحدة على حساب الأخرى.
هل توجد هذه التقنية في منظوماتنا المحلية؟
بسبب التعقيدات المصاحبة لهذه التقنيات وضرورة المحافظة على فرق التطوير والبرمجة بها والتي تسبق ضرورة تكوين هذه الفرق فإن العديد من الشركات يقوم بتكوين الفرق المطورة لكنه يغفل الحفاظ عليها مما يصاحبه من مسؤليات مالية ضخمة يحتاجها الفريق كرواتب ومصاريف تطوير والإضطلاع على التقنيات، مما يضطر بعض الشركات إلى تقليل المصاريف أو إستخدام النقنية بطريقة هجينة (تتطلب تقنية الطبقات الثلاث وجود جهاز عميل + جهاز خادم لإطار العمل + جهاز خادم لقاعدة البيانات لكن بعض شركات البرمجة تقوم بدمج أجهزة الخادم في جهاز واحد مما يحرم المستخدم النهائي من الإستفادة من هذه التقنية بطريقة جيدة) بل أن شركات البرمجة والمبرمجين في هذه الحالة يقومون بالعمل بتقنية (Client/Server) لكن مع بذل مجهود (N-Tier Application)، ومع وجود المنافسة القوية والعرض الكبير للمنظومات في مختلف المجالات بأسعار منخفضة فإن جودة البرمجيات تتجه نحو الإنخفاض كذلك،فمثلاً إذا أراد أحد الزبائن شراء منظومة للشؤون الإدارية قد يجد عرضين: الأول منظومة (Client/Server) بسيطة وبواجهة إستخدام جميلة بسعر 2000 دينار ليبي، ومنظومة أخرى تقوم بنفس العمل لكنها متعددة الطبقات وواجهتها ليست بنفس القدر من الجمال بالإضافة إلى أن سعرها لن يقل عن 10000 دينار ليبي بالإضافة إلى مصاريف المتابعة، فأيهما في رأيك سيختار؟ مع عدم نسيان أن كل مايريد المستخدم الحصول عليه هو تخزين بيانات ثم الرجوع إليها وتعديلها وطباعتها إذا تطلب الأمر.
هذا من وجهة نظري، ماهو رأيكم؟
2 comments:
اولاً نسيت التنبيه بأن تكون الهامبورجر "بدون بيض" فهذا شئ أساسي ومهم ;)
ثانياً :اوافقك الرئ ،فطريقة الطبقات المتعددة ليست فعّالة في المنظومات الصغيرة خصوص تلك التي ستعمل على جهاز حاسوب واحد ، فأنا شخصياً شاهدت مبرمجين قامو ببرمجة منظومة متعددة الطبقات لصيدلية مثلاً ففرضو على صاحب الصيدلية شراء جهاز حاسوب خادم وجهاز آخر عادي وقد عاني صاحب الصيدلية من كثرة الأجهزة وضجيجها وتكاليفها!!!!!
من أجمل ميزات الهامبورجر اسف أقصد التطبيقات المتعددة الطبقات، إمكانية إزالة أي طبقة قد تكون غير ضرورية لسير العمل، إما لتخفيض الوقت والجهد أو لرغبة المستهلك النهائي، وهذا أشد مايعجبني في التطبيقات متعددة الطبقات أسف أقصد الهامبورجر، فأنا لا أحب طبقة البيض
:)
Post a Comment