السلام عليكم ،

كيف حالكم جميعاً ،  لم أكتب من زمن طويل ..

لعل هذا القسم هو المناسب لهذا الموضوع ، كما هو الوصف :
 
"" وتنظيم المشاريع البرمجية. ""


رأيت نظام التدوين المتبع حالياً في الموقع .
النظام جميل ، ويبدو أنه مبني بأسلوب ممتاز .. بالنظر للوحة التحكم .

لا أعرف هل هو طلب شرعي عندما أقول :

ماهو الاسلوب المتبع في تصميم وهندسة هذا النظام ؟
كيف تم تقسيم طبقات النظام .. وكيف تتفاعل مكونات النظام ، والامتدادات ، مع بعضها .. ؟
هل استخدمتم Patterns معينة ؟

هناك عدة أساليب متبعة ، لعل أشهرها MVC ، Model-View_Controller ، وهو المستخدم بكثرة ، حيث يفصل أكواد المشروع الى ثلاث طبقات :
1- العرض .
2- التحكم .
3- منطق المشروع .

منطق المشروع بدوره ، قد يعتمد على Pattern معروف ، اسمه Data Access Object أو Data Access Layer .

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

سبب سؤالي هو مشروع التخرج الذي أعمل عليه حالياً ... والذي انقسم الى جزئين .. جزء ممتع و آخر ممل ..

الجزء الممل :
مشروع التخرج : 50% منه عبارة عن Web Application باستخدام لغة الجافا ، ويمكن تسميه موقع تفاعلي ..( JSP و Servelts وأمور أخرى ..) .
جزئية Web app ، سهلة ويعمل بشكل جيد ..
ولكن أشعر أن تصميم النظام ليش بالشكل الجيد .
هناك الكثير من اللخبطة والتداخل ..
كنت حللت و صممت المشروع بطريقة، والتنفيذ صار بطريقة أخرى ؟!

علاقات الجداول في الداتابيس ، متنوعة مثل : one-to-one و one-to-many و many-to-many ..
ولكن عند محاول تنفيذ فئات Classes تقابل تلك الجداول .. تجد أنه من الصعب أن تكمل بهذه الطريقة لتعقيد الكود بلا فائدة .

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

فهل هناك تجربة ممكن أن نستفيد منها ؟
هل تتقيدون بالـ Design Patterns المنتشرة بين المبرمجين ؟ أم كل مبرمج حر بالطريقة التي يستخدمها ؟

لا أعني أن أطلب رؤية تصميم وهيكلة نظام المدونات المستخدم في الموقع بالذات .. لأنه قد يكون طلب أحمق قليلاً 😒 .
ولكن لو أمكن  ايجاد أي مثال يوضح الفكرة .. للاطلاع على تجاربكم في هذا المجال .

وعليكم السلام أخي الشمري،
 
لعلي أقدر الأعضاء على الرد على سؤالك، حيث أني كنت على احتكاك طويل الأمد مع كود المدونة. وأعتذر عن عدم قدرتي على الرد مباشرة، فقد كنت أنتقل لمنزلي الجديد (باركوا لي ☺ ).
 
نظام المدونات جاهز لأي طلبات أو أسئلة تفصيلية عنه وهو تحت أمرك 😄 . وسأحاول أن أجيبك عن أسئلتك قبل أن نتابع وندخل في نقاش التفاصيل.
 
المشكلة في موضوع الـ patterns أنها عندما تتحول إلى كود فإن التعرف عليها يصبح أصعب. فالكود تفصيلي لأبعد الحدود، وأما الـ design patterns (أو فلنسمها أنساق التصميم) فهي مفاهيم عالية المستوى بدرجة كبيرة. لذلك غالباً تبقى الأنساق مجرد حبر على ورق، أما الكود فلا يـُظهر النسق المستخدم بشكل واضح. (هذا رأيي فقط، وقد يخالفني الكثيرون رأيي هذا 😒 ).

 


هممم. هناك أنساق عديدة مستخدمة في بناء النظام. لكن بداية بداية، نقول أنه مصمم على نفس الفكرة التي قلتها أنت. وهي الـ MVC. هناك طبقة عرض View Layer وطبقة معالجة وتخديم Business Layer وطبقة بيانات Data Layer. أعتقد أنهم يسمون هذا النظام بالنظام متعدد الأقسام Multi-Tier Design. وقد تعلمته أول مرة من كتاب دورة شهادة الـ MCSD الخاص بفيجوال سي 6.
 
الآن لو نظرنا إلى طبقة البيانات مثلاً، نجد أنها تعمل وفقاً لنسق واجهة التخاطب Interface Pattern. حيث أنه يوجد كلاس واجهة (في السي شارب هو interface). وهو يقدم كل الإجراءات التي تستطيع تنفيذها على قاعدة البيانات.  وراء هذه الواجهة يوجد لدينا ما يدعى التطبيق implementation. وهو على شكل كلاسين منفصلين. واحد يقدم قاعدة بيانات المدونة محفوظة في ملفات XML فقط (وهو المستخدم في المدونة الآن). والآخر يقدم قاعدة بيانات المدونة اعتماداً على SQL Server. يمكنك تحديد أي الكلاسين تستخدم ببساطة عن طريق ملف الـ WebConfig.xml الخاص بالموقع (هذا من خصائص ASP.NET).
 
نسق واجهة التخاطب Interface Pattern مستخدم بكثرة في المدونة. تقريباً أية وحدة يمكن أن تـُكتب بأكثر من طريقة أو تقنية نجعل لها واجهة موحدة interface ثم نكتب كلاسات خاصة بكل طريقة تقوم بعمل implementation للواجهة.
 



نفس المشكلة التي أواجهها باستمرار 😖 . ووجدت أن الطريقة الأمثل للتعامل معها هو أن أكتب الكلاس في أي مكان أريده. فمثلاً لو احترت بين طبقة البيانات وطبقة المنطق، فأختار واحدة منهما (على مبدأ حقرة بقرة قاللي عمي عد للعشرة). فيما بعد، وعندما أنتهي من وضع كافة الكلاسات في المشروع، تصبح الصورة عندي أفضل وأوضح بكثير، وعندها أقوم بنقل الكلاسات بين الطبقات وأعدل الكود وفقاً لذلك. 
يعني يمكننا تلخيص العملية بوصفها بأنها طريقة المسح المتعدد Multi-pass. حيث أن المسحة الأولى على المشروع تكون مرتبكة وغير منسقة، تأتي المسحة الثانية فتصلح الوضع وتنسقه، والمسحة الثالثة تجعل التصميم محكماً تماماً.
 



تماماً. رأيي أن لا تنزعج. فقط أكمل العمل بسرعة، ثم قم بعمل المسحة الثانية والثالثة لتصل للصورة المثلى. 



عني شخصياً لا أستخدم الكثير من الـ Design Patterns، لكني أكتشف بعد أن كتبت الكود بأن أحداً يخبرني أن هذا هو نسق الكذا وهو معروف. عموماً أكثر الأنساق التي أستخدمها هي واجهة التخاطب interface، والـ singleton (رغم أنني أكرهه) مع الكثير والكثير من التخبئة والتغليف encapsulation. فأحاول دائماً أن أبعد التفاصيل المعقدة عن الزبون قدر الإمكان.



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

تأخرت في الرد ، المعذرة .. ولكن كنت قرأت ردك في حينه .

أولاً مبروك المنزل الجديد 😄 ،

وشكراً على هذه المعلومات القيمة أخي ..




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





لقد سألت عن طريقة مناسبة في Java ، في منتدى آخر ، وذكروا لي مواصفات مماثلة تسمّى JDO .
وحاولت أن أعمل بطريقتي الخاصة .. فكتبت interface باسم DataAccess ، ويرث منها صنفان ، XmlDataAccess و DbDataAccess ،
المهم ، أني وصلت لمرحلة من الصعب أن اكمل فيها .. لأن التقنيتين مختلفتين تماماً ، وهناك صعوبة في تنفيذ استعلامات معقدة مثل :
هات جميع المستخدمين المنتمين للمجموعة أ علماً أن لهم الصلاحيات س و ص ، والتي تبدأ اسماءهم بحرف م .

في الاكس ام ال ، قد احتاج لتقنية مثل XQuery ، وفي النهاية سأصل لمرحلة معقدة .. فشلت الفكرة من رأسي ، ويكفي الان أن اتعامل مع قاعدة بيانات Relational

يبدو أن الأمور أجمل وأسهل في الدوت نت  .




تسلم أخي ..

لم أكن أقصد الكود نفسه ،  ولكن تصميم النظام بشكل عام ، ( كما تفضلت وشرحت ) ،
فمثلاً ، هناك نقطة لا أعرف كيف أطبقها وهي تتعلق بـ MVC :

هل ينبغي تصميم واجهات Interfaces ، تمثل كل طبقة .. بمعنى ، هل تملكون ثلاثة واجهات أساسية باسم :
Model :
View :
Controller :
وعلى ماذا تحتوي تلك الطبقات ؟

هل هذا الأسلوب جيد .. بأن نجبر أي كلاس ينتمي إلى Model ، أن يرث من الواجهة Model ؟
لأنه نظرياً .. من الصعب أن تكون كل الفئات Classes التي تنتمي لـ Model مثلاً .. ستشترك بدوال متشابهة !


شكراً لك أخ وسام مرة أخرى على هذه المعلومات :-) .

فعلاً. في دوت نت التعامل مع البيانات من XML سهل للغاية بتقنية لينك LINQ، والتي تمكنك من التعامل مع XML بطريقة SQL Query، حيث أنك تكتب تعليمات مشابهة جداً للـ SQL يمكنك تشغيلها على ملف XML أو حتى على قاعدة بيانات حقيقية كـ MySQL أو MS SQL.
 
من المثير أن أسماء الكلاسات التي انتقيتُها هي ذاتها التي أنت ذكرتها: DbDataAccess و XmlDataAccess 😄
 




كلا ليست هذه هي الطريقة التي يمكن تطبيق الـ MVC بها. لتقريب الصورة، يجب أن تكتب ثلاث طبقات منفصلة وكأن كل طبقة هي برنامج أو مشروع مستقل. 
لو نزلنا لمستوى الكود، أرى أن الفصل بين الطبقات طبعاً يظهر في توزيع الكلاسات في الملفات، إضافة إلى استخدام نطاق اسمي namespace خاص بكل طبقة. وفي كل نطاق، نضع الكلاسات المسؤولة فيه. مثلاً:
 
هيكلية بسيطة لطبقة البيانات:

namespace Data
{
   // واجهات التعامل
   public interface IDataAccess;
   public interface IDataConnect;
 
   // الكلاسات الفعلية
   private class XMLDataAccess : IDataAccess;
   private class DbDataAccess : IDataAccess;
}

 
طبقة المعالجة:

namespace Business
{
   // واجهات التعامل
   public interface IMember;
   public interface IAccount;
   public interface ISearch;
   public interface ISyndication;
 
   // الكلاسات الفعلية
   private class BasicMember : IMember;
   private class ModeratorMember : IMember;
   private class SupervisorMember : IMember;
 
   private class FreeAccount : IAccount;
   private class PaidAccount : IAccount;
 
   private class MemberSearch : ISearch;
   private class PostSearch : ISearch;
 
   private class RSSSyndication : ISyndication;
   private class AtomSyndication : ISyndication;



}

 
 
وأخيراً طبقة العرض:

namespace View
{
   public interface IPostView;
   public interface IMemberView;
   public interface ISearchView;
 
   private class HTMLPostView : IPostView;
   private class FlashPostView : IPostView;
   private class DesktopPostView : IPostView;
 
   // وهكذا
}

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

اه .. LINQ ، سمعت بها .. ولم أعرف فائدتها الا الان ..



 😲 ، ممتاز .. اختيار اسم معبّر من الامور المتعبة  بالنسبة لي ..


وضحت الأمور كثيراً الان .. بالنسبة للطبقتين Business و Data ، شكراً لك أخي وسام 😄

لكن هناك شيء غير مفهوم ، بالنسبة للطبقة View :

  private class HTMLPostView : IPostView;

أليس العرض هنا مبني على HTML و أوسمة ASP ،
بمعنى أن ما تريد عرضه موجود في ملفات asp وليس csharp .
فمالذي يمكن أن تحتويه هذه الفئة ؟

ما قمت به حتى الان ( أتكلم عن مشروعي ) ، هو أني اعتبرت ملفات jsp ( تقابلها بالدوت نت asp ) ، هي المسؤولة عن العرض ،
وبالتالي السيناريو هو التالي :

1- يأتي الطلب عن طريق الحدث Get مثلاً ،

index.jsp?component=article&id=10

2- يتم تحليل الطلب من قبل الصفحة index وتضمين الـ component الملائم - ( صفحة jsp أخرى ، ولنسميها article.jsp ) ، ونعطيها أيضاً بقية المعلومات المرفقة مع الحدث Get
3- الصفحة الأخرى سترسل الطلب الى كلاس معين الذي بدوره سيحلل ويتصل بالطبقة Business والتي ستتصل بالطبقة Data ، وفي النهاية تعود المعلومات الى الصفحة article.jsp
4- صفحة الـ jsp ، ستحوي على العرض فقط - أوسمة هتمل - ، مع بعض الجمل الشرطية والتكرارية ، و المتغيرات المخزنة ، المحقونة داخل الصفحة .


فسؤالي هنا ، هو عن HTMLPostView  ، الذي لا أعرف مالذي سيفعله .. في ظل وجود صفحة asp ما .. مسؤولة عن العرض ، والتي تقوم بتضمين صفحات asp أخرى ( أعتقد يسمونها بالـ master page في asp ) .

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

public interface IPostView
{
   void RenderPost(IPost post);
   void RenderMultiplePosts(IPost[] post);
   void FocusPost(IPost post);
}

 
في حال كلاس الـ HTMLPostView فإنه يقوم بإرسال طلب الـ RenderPost إلى كلاسات ASP.NET كي تقوم بتخريج كود الـ HTML المناسب لعرض المشاركة مثلاً. في ASP.NET تستطيع فعل ذلك عن طريق تحميل قالب للمشاركة (يدعى UserControl) وتعبئته بمعلومات المشاركة، وأخيراً إضافته لصفحة الـ ASP.NET كي يقوم محرك ASP.NET بتحويلها بضربة واحدة إلى أكواد HTML ترسل لمتصفح المستخدم.
 
تفاصيل استخدام صفحة التصميم الرئيسي Master Page وما إلى ذلك كلها يعالجها كلاس الـ HTMLPostView بمجرد إنشائه (في الـ Constructor).
 
بقيت التفصيلة الأخيرة، وهي أن هناك كود معني بتلقي الطلبات من المستخدم والرد عليها، وهو الكود الخاص بكل حل. فمثلاً موقع الإنترنت يتلقى الطلبات ضمن إطار عمل ASP.NET بينما البرنامج المكتبي يتلقاه ضمن أحداث الضغط على أزرار WinForms، وهكذا.
 
كنتُ أتمنى لو أنني عملتُ أكثر بالجافا في المواقع، لكني للأسف لم يتحْ لي ذلك سوى مرة واحدة بالتعاون مع مختص كان هو من وضع التخطيط عالي المستوى للموقع وترك لي تفاصيل حشو الإجراءات فقط. 😳   أرجو أن تكون أمثلتي عن ASP.NET واضحة لك 😨

الأمور واضحة الان على مستوى جميع الطبقات 😄 .
شكراً لك أخي ..