تطبيقات الويب - الجمع أو منفصلة؟

Question

بالنسبة لشركتنا ، أقوم بإنشاء موقع ويب كبير Extranet والذي سيحتوي على مجموعة من التطبيقات الفرعية. أنا في حيرة من ما ينبغي أن يكون الإعداد الصحيح للحل والمشاريع.

لدي تطبيق ويب واحد نسميه البوابة. أنه يحتوي على فئات المصادقة/التفويض ، والرسملة ، وفئات توجيه الملاحة/عنوان URL وتعريفات الموضوع. سيحتوي أيضًا على بعض نظرة عامة أساسية لعملائنا للحصول على فكرة سريعة عن حالة مشروعهم.

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

ما هي الطريقة الصحيحة لإعداد هذا الحل؟
كيف يمكنني ربط التطبيقات معًا ، وإعادة استخدام الصفحات الرئيسية والحفاظ عليها قابلة للصيانة؟
كيف يمكنني مشاركة بعض WebControls (ASCX) بطريقة مناسبة؟
نحن نستخدم TFS ، ربما أي أفكار المتفرعة/دمج؟

يحرر:
أرغب في إنشائها في WebForms ASP.NET ، لدينا أكبر خبرة في هذا المجال. ولكن في الأساس يمكننا استخدام أي شيء ، لدينا خادم الويب تحت سيطرتنا الخاصة (طالما أنه موجه نحو Microsoft ، وليس التحول إلى PHP أو شيء من هذا القبيل :))

Answer 1

What is the proper way to setup this solution?

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

نظرًا لأنك تقوم ببناء بوابة ، سيكون لديك رفاهية فصل الميزات والتي ستساعدك أثناء تطوير ميزات إضافية لتطبيقك.

أود إعداد موقع ويب واحد مع مجلد منفصل لكل ميزة. إن جعل موقع ويب واحد يسمح لجميع الميزات بمشاركة نفس الأمراض ، و usercontrols ، وملف التكوين - دون الحاجة إلى القيام بأي شيء مميز. (في تلك المذكرة ، أود أن أضع جميع صفحاتك الرئيسية في مجلد بمفردها ، وأنشئ مجلد آخر لجهاز UserControls).

How can I tie the applications together, re-use the master pages and keep it maintainable?

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

How can I share certain webcontrols (ASCX) in a proper way?

بادئ ذي بدء ، فإن ملفات ASCX ليست WebControls. هم UserControls. WebControl هي فئة لإنشاء عناصر تحكم الخادم الموجودة في مجموعة منفصلة. فيما يتعلق بـ UserControls ، كما قلت أعلاه ، إذا وضعتها في مجلد منفصل ، فهي دائمًا في مكان واحد ومتاحين في جميع أنحاء التطبيق.

We are using TFS, perhaps any branching/merging ideas?

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

• واحد هو إنشاء فرع لكل إصدار.
• آخر هو إنشاء فرع لكل ميزة جديدة تضيفها (في حالتك ، وهذا هو نفس الخيار الأول).
• آخر هو إنشاء فرع لكل مطور.

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

Answer 2

كما يقول براين عند إعداد API للجمهور ، يجب عليك الالتزام بها قدر الإمكان ، مما يعني أنه يجب أن يتغير أقل قدر ممكن بعد الإصدار الأولي. ومع ذلك ، فإن صنع شيء مستقر يتطلب الكثير من الجهد في المقدمة ، لذا إذا لم تكن مستعدًا للالتزام بأجهزة واجهة برمجة التطبيقات ، فيجب عليك بدلاً من ذلك استيعابه قدر الإمكان ولهذا السبب قد ترغب في الجمع بين الأشياء أكثر من فصلها.

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

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

نرى:
1. ما هو أفضل ، العديد من التجمعات الصغيرة ، أو مجموعة كبيرة واحدة؟
2. جوانب محددة لكثير من التجميعات؟

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

فيما يتعلق بالاستراتيجيات المتفرعة ، يمكنك قراءة TFS المتفرعة التوجيه 2.0 التي لديها مقدمة جيدة إلى استراتيجيات متفرعة مختلفة تتراوح من الأساس إلى المتقدم. حتى لو لم تستخدم TFS ، فهذا دليل جيد للقراءة (أستخدم SVN في الوقت الحالي). نظرًا لأنني أعمل حاليًا في فرق صغيرة مع 1-4 devs ، فإنني أميل إلى استخدام استراتيجية بين الأساسي والمعياري. لا أوصي بهذا من أجلك ، لكن هذا أفضل لفريقنا.

أما بالنسبة لمشاركة التعليمات البرمجية بين المشاريع. في SVN يمكننا استخدام "العوامل الخارجية"مما يعني أن الملف المشترك سيظهر في العديد من المجلدات ، لذلك عندما تقوم بتغيير نسخة واحدة وارتكاب التغيير إلى SVN ، سيتم تحديث جميع النسخ الأخرى في تحديث SVN التالي. ومع ذلك ، لا يمكنني تذكر ما إذا كان لدى TFS شيئًا مشابهًا .

ملحوظة: احذر من الخارجيات في SVN ... يمكن أن تسبب ... مشاكل. ؛)

نصيحتي هي محاولة تجنب مشاركة صفحات ASPX و ASCX و Master Accain قدر الإمكان. عادة ما يؤلمني أكثر مما يساعد. بدلاً من ذلك ، حاول استخدام الميراث أو بدائل أخرى لتحقيق هدفك.

يحتوي ASP.NET MVC 2.0 على مفهوم يسمى "المناطق" حيث تقوم بإنشاء أقسام فرعية من التطبيق بمعزل عن الباقي. بقدر ما أعرف يمكن الحفاظ على هذه المناطق في مشاريع منفصلة عن التطبيق "الرئيسي". يبدو الأمر يشبه إلى حد كبير ما تطلبه ، لذا ربما يجب عليك النظر في ذلك.

أتمنى أن يكون من المنطقي. ؛)

Answer 3

أود أن أنظر في جعل نظامك المتباعدة بقدر الإمكان. As/عند إضافة المزيد من التطبيقات ، سيصبح موقع الويب الخاص بك أقل موثوقية (نظرًا لعدم وجود مكون بنسبة 100 ٪ من الوقت ، فإن الجمع بينها سيقلل من موثوقيك العام). لذلك يجب عليك بناء نظامك لتلبية احتياجات الخدمات غير المجرات (أعتقد أن صفحة Amazon الرئيسية ، على سبيل المثال ، لديها 100 خدمة تسهم في ذلك ، وبالتالي تم تصميمها لتكون متحملة للأخطاء)

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

Answer 4

قد تجد أنه من المفيد النظر في تنفيذ العرف VirtualPathProvider. في مشروعي الأخير ، كان لدينا العديد من مواقع ASP.NET التي تحتاج إلى مشاركة ملفات السمات (الصفحات الرئيسية ، عناصر التحكم في المستخدم ، الصور ، أوراق النمط) لذلك قمت بإنشاء VirtualPathProvider الذي سمح لنا برسم خريطة مجلد افتراضي (على سبيل المثال /سمات) المجلد على القرص الصلب (على سبيل المثال C: مشترك siteThemes).

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

Answer 5

استخدم مفاهيم MVC من الآن. أنها تعطي المزيد من القابلية للتمديد والمرونة لتطبيقات قوية.

Answer 6

قد تنظر في استخدام SharePoint. إنها منصة لائقة جدًا لتسليم تطبيق ASP.NET ، خاصة إذا تعايشوا في بيئة إنترانت ؛ يمنحك الكثير من الأشياء مجانًا.

بالطبع ، لديها مرفقين تقريبين للغاية ، إذا جاز التعبير ، لذا تابع بحذر.

Answer 7

لا أفكر في التطبيقات على أنها منفصلة ولكن كوحدات للبوابة الكلية.

أود أن أوصيك بالنظر إلى MEF لأن هذا يبدو أنه مناسب تمامًا.

http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx