إطار عمل | يحاكي عمل الخدمة البريدية لتقليل الاعتمادية وتشابك الارتباطات

السلام عليكم ورحمة الله وبركاته

بسم الله الرحمن الرحيم

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

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

الفكرة تقوم على محاكاة الخدمة البريدية والطرد المغلف

ملاحظة الأمثلة سأضربها بلغة سي شارب #C ولكن الفكرة عامة

حيث أنشأت واجهة Interface أسميتها IRequestable لها منهج واحد وهو Submit له مدخل وهو مصفوفة أوبجكت params object[] وله خرج هو فئة أسميتها DataStore أو يمكن تسميتها

namespace RequestableFrameWork
{
    public interface IRequestable
    {
        DataStore Submit(params object[] args);
    }
}

و هي ديناميكية تمثل الصندوق الأسود أو الطرد البريدي تقوم الفكرة أن أي موديول من أي طبقة بأي اسم نطاق لا يمكنه التعامل مع أي موديول آخر إلا من خلال القناة Submit والتي تمثل نافذة تقديم الطلبات واستلام الإجابات فبدلا من أن نجعل موديول ما يصل إلى موديول آخر عبر مناهجه والتي تحتم علينا تضمين المكتبة في الطبقة الأخرى ضمن الطبقة المقصودة فضلا عن جعل الفئات مرئية وكذلك المناهج ويجب معرفة مدخلات المنهج وأنواعها و الإرجاع يكون وحيدا بدلا من هذا يقوم الطالب بتقديم طلب عبر الدالة Submit مع تمرير عدد لا محدود وليس مقيد من المعطيات في حال لزمت أثناء تقديم الطلب لاننا كما قلنا المدخل هو مصفوفة أوبجكت params object[] والتي ستتحول إلى نوع DataStore ضمنا أي وكأننا وضعناها بصندوق وغلفناه وأرسلناها للجهة المعنية

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

بناء على نوع الطلب يتفرع عبر تعليمة switch بحيث يتابع عملية التنفيذ

بناء على نوع الطلب هو يدرك مالذي يتوجب عليه فعله فيقوم باستخراج المعطيات التي يحتاجها لإتمام الطلب والتي يتوقع وجودها في صندوق المعطيات

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

طبعا الواجهة Interface ستكون في مكتبة مستقلة يتم إضافتها للجميع أي جميع الطبقات وبالتالي أصبح كل الفئات بالنسبة لبعضها البعض هي عبارة عن واجهة بقناة اتصال يتم تقديم الطلب من خلالها مدخلين مجموعة معطيات ليعود الجواب محملا بنفس الصندوق

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

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

هذا من حيث المبدأ العام وقبل الدخول بتفاصيل التنفيذ

كما أن هناك تتمة لإطار العمل يعتمد على مبدأ الفراشين في المؤسسات سأتطرق إليه لاحقا إن شاء الله

كما قلت فقد دخل حيز التنفيذ فعلا ولكن طرحته من باب المشاركة ولتبادل وجهات النظر والاقتراحات من باب التطوير وتعميم الفائدة

ودمتم برضى من الرحمن

عبد الرحمن أحمد

27-02-2014