يجب أن تكون طبقة العمل من التطبيق قادرا على الوصول إلى كائن الجلسة؟

Question

قل لديك 3 طبقات: واجهة المستخدم، الأعمال التجارية، البيانات.

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

أنا استخدم C # 2.0 .NET

Answer 1

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

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

تحرير: يجب استخدام واجهة المستخدم فقط للقيام بما يلي: 1. اتصل على طبقة العمل. 2. تفاعل مع المستخدم (الرسائل والأحداث). 3. معالجة الكائن المرئي على الشاشة.

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

Answer 2

لا. إذا كان لديك طبقة "وحدة تحكم"، يجب عليك الوصول إليها هناك. احصل على ما تحتاجه من الجلسة وتسليمها إلى طبقة عملك.

Answer 3

تنهد.

الإجماع الواسع سيكون لا؛ يجب الحفاظ على طبقة العمل وطبقة تحكم / ويب بشكل مختلف، لأنها مخاوف منفصلة.

والحقيقة هي أنه يبدو أنك تسمية هذا باعتباره سؤال "النقاء مقابل الواقع" وهو ما يظهر بشكل لا يصدق البصر والغيض قليلا. كما يتحدى نقطة طرح السؤال؛ إذا كنت لن تفكر في عرض الآراء، فلماذا التماسهم؟

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

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

ما يصل إلى هذه النقطة، واجهة المستخدم هي كلها غير مادية؛ لا يهم إذا كان دخول المستخدم، أو بيانات العملاء في تطبيق سطر الأوامر، أو قم بالتنقل إلى بعض النموذج المتعدد الصفحات مع البيانات المخزنة في الجلسة. دعنا نقول أنك تختار الأخير؛ عصا ويب الواجهة الأمامية على ذلك. الآن ما كنت مهتما هو كتابة رمز بسيط نسبيا للتعامل مع استرداد البيانات المطلوبة وتقديمها للمستخدم. النقطة هي، تطبيق الويب الخاص بك؛ الواجهة الأمامية، الذي - التي هي واجهة المستخدم بأكملها؛ جلسات وجميع. فقط عند الاستعداد الذي أنت مستعد ليقوله، "مهلا، دعونا نلتزم أن بيانات العميل في قاعدة البيانات" هل تذهب واستدعت طبقات خدمة OH-BO-LOVUVE التي وضعت بمحبة، تمر كل جزء من المعلومات التي حصل عليها تطبيق الويب الخاص بك مخبأ إدخال المستخدم، اسم المستخدم الذي يحدث التغيير؛ كل هذا حماقة. وطبقة الخدمة الخاصة بك تتعامل معها. أو، بدلا من ذلك، الكلبات "لأنك نسيت حقل مطلوب.

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

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

Answer 4

الروائح مضحكة لي. ربما تحتاج إلى طبقة عرض تقديمي لإدارة الجلسة وأي معلومات أخرى أو معلومات أخرى؟

Answer 5

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

Answer 6

أفكر في الاستخدام غير الضروري للجلسة ليكون رائحة كود بشكل عام، في كثير من الأحيان الاستعلام، ملفات تعريف الارتباط والشاهد هي الوزن الخوف ولديها أفضل "مجال"

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

على سبيل المثال، في تطبيق Console، تطبيق ASP.NET Web، خدمة Windows، تطبيق Windows Forms - فقط جلسة.

ومع ذلك، فإن القدرة على دعم Mutliple UIS هي ميزة مبالغا فيه للغاية ولا تتخذ تبصر مثالي لتقدير ما إذا كنت ستنفذ تطبيقك إلى واجهة مستخدم مختلفة. إذا كنت واثقا للغاية من أن منطقك لن يتم تشغيله فقط في تطبيق ASP.NET من الآن وإلى الأبد، فلا بأس بذلك.

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

Answer 7

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

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

Answer 8

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

على سبيل المثال، في تطبيقنا لدينا قاعدة بيانات لكل عميل، ولكن قاعدة رمز واحد. لذلك لدينا معلومات العميل في الجلسة لكل مستخدم. بالتأكيد، يمكننا بعد ذلك سحب البيانات خارج الجلسة في طبقة الويب ثم نقلها إلى طبقة العمل. بالطبع، لا يهتم طبقة العمل بذلك، ولكن هناك حاجة إليها من خلال طبقة البيانات للاتصال بقاعدة البيانات الصحيحة. لذلك، ستحتاج طبقة العمل إلى نقلها إلى طبقة البيانات. يبدو وكأنه الكثير من المعلمة تمر دون سبب عمل جيد. في حالتنا، يتحقق طبقة البيانات الخاصة بنا كائن الجلسة للحصول على سلسلة الاتصال ويعمل من هناك. ترميز حول مسألة عدم وجود جلسة إذا لم يكن تطبيق ويب (ولدينا تطبيقات Windows Services و .exe Helper) كما يلي:

protected virtual string GetConnectionString()
{
string connectionString;
string connectionStringSource;

//In app.config?
if (ConfigurationManager.AppSettings[_ConnectionStringName] != null &&
   ConfigurationManager.AppSettings[_ConnectionStringName] != "")
{
   connectionString = ConfigurationManager.AppSettings[_ConnectionStringName];
   connectionStringSource = "Config settings";
}
//Nope? Check Session
else if (null != HttpContext.Current && null != HttpContext.Current.Session &&
   null != HttpContext.Current.Session[_ConnectionStringName])
{
  connectionString = (string)HttpContext.Current.Session[_ConnectionStringName];
  connectionStringSource = "Session";
}
//Nope? Check Thread
else if (null != System.Threading.Thread.GetData(
      System.Threading.Thread.GetNamedDataSlot(_ConnectionStringName)))
{
   connectionString = (string)System.Threading.Thread.GetData(
          System.Threading.Thread.GetNamedDataSlot(_ConnectionStringName));
   connectionStringSource = "ThreadLocal";
}
else
{
   throw new ApplicationException("Can't find a connection string");
}

if (debugLogging)
   log.DebugFormat("Connection String '{0}' found in {1}", connectionString, 
          connectionStringSource);

return connectionString;
}

Answer 9

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

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

على سبيل المثال، أقول أنك تريد استخدام مجموعة واحدة من الكائنات لمتغير جلسة واحدة ومجموعة أخرى لمتغير آخر. يمكن لمراقب التحكم عن طبقة خدمة وتمرير في المتغير. ستجد طبقة الخدمة بعد ذلك كائن الأعمال المناسب.

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

Answer 10

يرتبط كائن الجلسة بتنفيذ واجهة المستخدم المحدد، لذلك توفي طبقة عملك في دورتك هي رائحة.

بالإضافة إلى ذلك، ربما يجب أن تكون قادرا على اختبار طبقة عملك - كيف ستفعل ذلك إذا كان هناك تبعيات في جلسة؟