التاريخ الذي تم إنشاؤه - هل يجب تعيين هذه القيمة في BL أو DAL؟

Question

أنشأ التاريخ مثالًا محددًا أنا مهتم به - ولكن هناك أجزاء أخرى من البيانات تندرج في نفس الفئة: البيانات التي تريد التقاطها حول أي كيان مهم بشكل غامض.

أين أفضل للقيام بذلك: منطق الأعمال (BL) أو طبقة الوصول إلى البيانات (DAL)؟

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

FYI - لقد كان هذا بشكل أساسي في أنظمة قائمة على الويب حيث تقوم بإنشاء كائن في BL (استنادًا إلى إدخال المستخدم) وإطلاقه في DAL - ليس الأمر كما لو كنت أرغب في الرجوع إلى الكائن في الذاكرة على مر العصور (لذا فإن وجود خاصية "تاريخ تم إنشاؤها" على الكائن للاستخدام في BL عند إنشاء الكائن لم يكن مشكلة).

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

Answer 1

أود أن أقول: نعم.

ربما احصل على عادة تحديد التواريخ التي تم إنشاؤها وآخرها في BL. ثم في DAL الخاص بك ، كن دائمًا تحقق من خام في تلك الحقول. إذا كانت فارغة ، ففكر في خيارك: رمي استثناء ، أو مجرد ملء تلك القيم في تلك الطبقة. نوع من الصيد قبل إدراج/تحديث.

كان لدي نفس النمط الذي تصفه في سؤالك. بعد ذلك ، واجهت استخدام التطبيق/استهلاك الطوابع الزمنية لـ UTC ، وتصورت أنني كنت أقوم فقط بنقل هذا السلوك إلى فئات BL و/أو DL. نعم ، كان بإمكاني استخدامها GETUTCDATE(), ، ولكن شعرت أكثر ملاءمة للحصول على هذا المنطق في BL/DL.

Answer 2

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