أفضل الممارسات: العمارة 3 طبقات في LINQ

Question

وأنا أعمل على مشروع شخصي (C # / ASP.NET) التي سوف تستخدم LINQ إلى SQL. فإن الحل يكون (حتى الآن) مشروع نموذج الويب، وهو مشروع النطاق (منطق الأعمال)، ومشروع الاختبارات. أنا في المراحل المبكرة جدا حتى الآن (بشكل واضح في مرحلة التصميم).

هل هناك نموذج لمدة 3 طبقات العمارة هنا؟ ويبدو أن DAL لا طائل منه تماما في هذه الحالة؛ وكأننا أرجو أن أداء الاستعلام LINQ مباشرة من منطق الأعمال.

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

ولقد وجدت هذا الموضوع ، لكنه يبدو أن ترسم صورة غير كاملة. هل هناك أي مقالات متعمقة حول هذا الموضوع؟

Answer 1

ويمكنك ان تفكر في-LINQ إلى SQL كما DAL الخاص بك، وذلك باستخدام أنها "مباشرة من منطق الأعمال" ليست بالضرورة أمرا سيئا.

<وأ href = "http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx" يختلط = "نوفولو noreferrer "> http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx لديها بعض الأساليب L2S شعبية المدرجة .

في مشروعنا، لأننا لا نريد أن يمر حول سياق البيانات بحيث كنا نمطا مماثلا لرقم 3 من الرابط أعلاه (المحيطة DataContext، انظر أدناه). وكان بعض القضايا، لكنها عملت بشكل معقول. على الأقل بالنسبة للمشروع على شبكة الإنترنت.

<اقتباس فقرة>   

والمحيط DataContext (حاليا استخدام هذا)

     

والفكرة وراء datacontext المحيطة هي يتم إنشاء هذا السياق لموضوع معين أو httpcontext (في asp.net) في أقرب وقت هناك دعوة الأولى لDataContext. ثم يتم استخدام السياق ذاته عن أن موضوع أو طلب ما لم يتم التخلص منها يدويا. ويتم ذلك عن طريق تخزين السياق في مخزن البيانات الطلب / الموضوع. النهج المتبع في هذا النمط يشبه ثابت DataContext، ومع ذلك، يتم توفير فصل لكل موضوع والطلبات. هذا يعمل بشكل جيد في Asp.Net، ومع ذلك، تعاني مرة أخرى من قبل بعض المشاكل السياق ثابت.

     

ومشاكل مع هذا النمط:

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough

Answer 2

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

ومع ممارسة تصميم مدفوعة المجال (DDD)، لديك "نموذج المجال 'الغنية، في المكان الذي يعبر عن نطاق المشكلة التي تريد معالجة. يتكون هذا النموذج مجال الطبقات (والبنيات) التي كنت نموذجا الكيانات التجارية الخاصة بك. consits على نموذج المجال أيضا المستودعات.
مستودع هو نوع من التجريد التي تستخدمها في نموذج المجال الخاص بك (وفي التطبيق الخاص بك)؛ المستودع هو فكرة مجردة من مخزن البيانات الخاص بك. من خلال المستودع، يمكنك استرداد الكيانات، ويمكنك استخدام مستودع للاستمرار الكيانات.

في الحالة الخاصة بك، يمكن أن المستودعات الخاصة بك استخدام LINQ إلى SQL داخليا لاجراء محادثات مع قاعدة البيانات. لكن لاحظ أن المخزون الخاص بك لا ينبغي أن يكون مسؤولا لإدارة (فتح / وثيقة) الاتصال والصفقة (بدء / الالتزام / تراجع) على الرغم من. لماذا ا ؟ -> لأن مستودع لا يوجد لديه معرفة أو فكرة السياق الذي يتم استخدامه. ومن طلبك أو خدمة طبقة (طبقة يستخدم نموذج المجال الخاص بك، وبالتالي المخزون الخاص بك) التي يجب أن تكون مسؤولة عن فتح اتصال جديد وبدء / تنفيذ المعاملات. (أو في قضيتك، فتح DataContext جديد). يمكنك بعد ذلك تمرير DataContext إلى المخزون.

و(اريك ايفانز لديه الكتاب العظيم فيما يتعلق DDD، وإن كانت مهمة شاقة للقضاء، من وقت لآخر).

Answer 3

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

وA العمارة ثلاث طبقات لا تزال فكرة جيدة عند استخدام أداة ORM مثل LINQ-لSQL. وDAL يصبح مجرد مكان لتخزين منطق الاستعلام الخاص بك. ه فكرة جيدة لاتخاذ استفساراتكم من طبقة رجال الأعمال الخاصة بك لالاستعلامات مصدر قلق استمرار، وليس مصدر قلق منطق الأعمال.

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

في مجال المواد الأخرى حول هذا الموضوع يمكنك أن تبحث في أي توجيه العمارة لأي أداة ORM - ينق-إلى SQL لا يختلف. بحث عن مقالات حول الهندسة المعمارية للNHibernate.

Answer 4

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

إذا كان لديك بعض الاحتياجات الأخرى، على سبيل المثال الخاصة مزود LINQ الخاص الذي يربط لغير MSSQL-دعم البيانات، فإنك سوف تنفذ DAL الخاصة بك.

وبالإضافة إلى ذلك فيما يتعلق DataContext، فمن غير المستحسن استخدام نمط المفرد مع "DataContext أحد السكان". يجب أن تمثل كائن DataContext صفقة منطقية واحدة، أيا كان ذلك يعني للتطبيق الخاص بك. (اقتباس من <لأ href = "http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx" يختلط = "نوفولو noreferrer "> http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx )