البيانات / التخزين المؤقت بين الطلبات - النهج المشترك

Question

أقوم بتطوير تطبيق ASP.NET (MVC ولكن هذا لا يهم حقا). لدي مخصص IHTTPModule مسؤولة عن postauthenticaterequest لتغيير مدير المستخدم والهوية.

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

لذلك أنا أفكر في كيفية وأين سيكون من الأفضل أن تستمر بتسجيل الدخول بيانات IUSER للمستخدم؟

1. لا أريد جلبها في كل مرة من DB (بناء على بيانات معرف المستخدم تذكرة المصادقة)
2. لا أستطيع تخزينها في الجلسة لأنني لا بد لي من العمل داخل postauthenticaterequest، حيث ليست الجلسة جاهزة بعد
3. أريد أن يتم تغليف جميع الوظائف داخل مخصص IHTTPModule

الخيارات التي أراها:

• مخبأ
• بسكويت
• (جلسة) - عن طريق الانتقال من postauthenticaterequest إلى حدث ما بعد postacquirerqueststate وتغيير الرئيسية / الهوية هناك، ولكن أود تجنب هذا

العمليات التي يبدو أنها تعقد الأمور هي:

1. سجلات المستخدم، يتم جلب بيانات المستخدم من DB واستمرت بطريقة أو بأخرى في وقت لاحق
2. تسجيل الدخول المستخدم، يجب إزالة بيانات المستخدم من المتوسطة المستمرة
3. يقوم المستخدم بتغيير ملف التعريف الخاص بالملف الشخصي، ويجب التخلص من بيانات المستخدم وإعادة توجيهها في الطلب التالي من DB

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

ما لا أريده أيضا أن أكتب / اقرأ بعض المتغيرات / المفاتيح المضغوطة ومعالجتها في أجزاء أخرى من التطبيق. هذا لن يقدم فقط الديون الفنية.

أسئلة

1. ما اقتراحك؟
2. كيف تستمر في ذلك بيانات المستخدم بين الطلبات؟

Answer 1

بالنظر إلى الاحتياجات الخاصة بك، أفترض أن أفضل حل هو استرداد المعرف من ملف تعريف الارتباط واستخدامه إلى الفهرس في ذاكرة التخزين المؤقت HTTP (HTTPCONTEXT.CURRENT.CACHE).

إذا كنت ترغب في الحفاظ على كيفية الوصول إليها للمستخدمين، فافت ذاكرة التخزين المؤقت كائن "Usercache". يمكن إنشاء الكائن بواسطة httpModule وتخزينه كعمل (انتظر به ...) Singleton داخل ذاكرة التخزين المؤقت نفسها أو، الأفضل من ذلك، مصنوعة فقط عند الحاجة لسحب ذاكرة التخزين المؤقت HTTP. يعتمد هذا على المكان الذي تحتاج فيه إلى الوصول إليه وما إذا كان httpContext.current.cache متاح مباشرة. التنفيذ كسول أدناه.

مرة أخرى، هذا هو من أجل الوضوح وليس كيف يمكنني تنفيذها بالفعل.

public class UserCache
{
  public IUser GetUser(object userKey)
  {
    return HttpContext.Current.Cache[userKey];
  }

  public void AddUser(object userKey, IUser user)
  {
    /* this could pull the key from the user object as well. */
    HttpContext.Current.Cache.Add(/* add the object with key and a sliding expiration that is slightly greater than session timeout */);
  }

  public void ExpireUser(object userKey)
  {
    HttpContext.Current.Cache.Remove(userKey);
  }

  /* If you don't want to do SQL cache dependency */
  public void UpdateUser(object userKey, IUser user)
  {
    HttpContext.Current.Cache.Insert(/* ... */);
  }
}

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

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

في HttpModule نفسه، أفترض أنك يمكن أن تفعل بعض السحر في حدث EndRequest لمعرفة ما إذا كان الطلب مصادقة، ثم قم بتسجيل المستخدم على استنادا إلى ملف تعريف الارتباط، لكنني لست متأكدا مما إذا كان ذلك سيعمل كما لم أحاول أبدا هو - هي. قد ترغب في إلقاء نظرة على هذه المقالة على MSDN من الطريق مرة أخرى في أيام 1.1 وأرى ما إذا كان يجيب على بعض المشكلات التي تحاول حلها.

بالنسبة للهندسة المعمارية، وكيف يفعلون ذلك، سأتخيل أنها تحميلها عند الحاجة لأنها تبقي معظم قاعدة البيانات في ذاكرة الوصول العشوائي في جميع الأوقات (http://highscaliability.com/stack-overflow-architecture.).