تقليل تعقيد طبقة تطبيق قائم على Cairngorm

Question

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

ما أفعله حاليًا هو اتباع جميع إرشادات Cairngorm ، والتي أدت بالفعل إلى مجموعة من الأوامر التي تعتبر جميعها منطقية ، ولكن بما في ذلك مندوبي الأعمال وكل هذه الأشياء ، فأنا أواجه صعوبة في التمديد وإعادة البناء التطبيق (وفي الواقع كان من المفترض أن تساعد الطبقات ، ضيقة ... ربما لا أقوم بذلك بشكل صحيح ، أعترف).

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

ما أعنيه بذلك: ربما يمكنني ربط نقرة زر بنمط عنوان url (أو استخدام SWFaddress لتغيير عنوان url عالميًا). من ناحية أخرى ، سأنتظر تغييرات عنوان url ، وأعيد تنسيقه ، وأرسله إلى مندوب الخدمة ، الذي لديه التعيينات الضرورية في الاعتبار ، حتى يعرف طريقة الاتصال ، أو يمكنه حتى تمرير عنوان url مباشرة إلى HTTPSErvice. سيقوم المفوض بعد ذلك بالتعامل مع استجابة الخادم ، وتحديث النموذج ، والذي سيتم من خلال الارتباطات تحديث العرض.

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

هل أنا على الطريق الصحيح؟

Answer 1

هل أنت مستعد للتبديل إلى إطار عمل بديل عن Cairngorm؟ لقد وصفت تمامًا ما هي شكاوى معظم الناس حوله. أعتقد أنه موجود في الغالب من أيام رجوع تطوير Flex ...

يستخدم معظم المطورين الذين أعرفهم إطار عمل "حديثًا" يركز عادةً على حقن التبعية (DI).

هذه نقطة بداية جيدة في تحليل الإطارات المختلفة المستخدمة اليوم:

http://www.adobe.com/devnet/flex/articles/ flex_framework.html

ولمزيد من القراءة ...

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

إذا كانت أسئلتك هي كيف يمكنني أن أجعل Cairngorm أقل شبهاً ... حسنًا Cairngorm ... فأخشى أنه لا يمكنني مساعدتك هناك. :)

تحياتي ونتمنى لك التوفيق!