سؤال

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

  1. هل انتقل أي شخص آخر من NetTiers إلى LINQ إلى SQL؟
  2. هل كان هذا التبديل أمرًا جيدًا أم سيئًا؟
  3. هل هناك أي شيء يجب أن أكون على علم به؟
  4. هل تنصح بهذا التبديل؟

في الأساس أرحب بأي أفكار.

هل كانت مفيدة؟

المحلول

  1. لا
  2. انظر رقم 1
  3. يجب عليك الحذر من التجريد القياسي.كما أنه SQL Server يعتمد على حالته الحالية.
  4. هل تستخدم SQL Server، إذن ربما.إذا كنت تستخدم LINQ لأشياء أخرى في الوقت الحالي مثل بيانات XML (رائعة)، وبيانات الكائنات، ومجموعات البيانات، فنعم، يجب عليك التبديل للحصول على بنية بيانات موحدة لكل منها.يحب lagerdalek المذكورة إذا لم تكن مكسورة فلا تصلحها.من خلال إلقاء نظرة سريعة على .netTiers Application Framework، أود أن أقول إنه إذا كان لديك بالفعل استثمار في هذا الحل، فيبدو أنه يوفر لك أكثر بكثير من مجرد طبقة وصول بسيطة إلى البيانات ويجب عليك الالتزام به.

من تجربتي، يعد LINQ إلى SQL حلاً جيدًا للمشاريع الصغيرة والمتوسطة الحجم.إنها ORM وهي طريقة رائعة لتعزيز الإنتاجية.إنه أيضًا يجب يمنحك طبقة أخرى من التجريد تسمح لك بتغيير الطبقة الموجودة أسفلها لشيء آخر.المصمم في Visual Studio (وأنا أؤمن بـ VS Express أيضًا) سهل الاستخدام للغاية.فهو يوفر لك إمكانية السحب والإفلات الشائعة والتحرير المستند إلى الخاصية لتعيينات الكائنات.

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

موارد:

لاحظ أن لينك الموازي يتم تطويره للسماح بأداء أكبر بكثير على الأجهزة متعددة النواة.

نصائح أخرى

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

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

الدفع سلسلة LINQ إلى SQL من سكوت جوثري من منشورات المدونة للحصول على بعض الأمثلة الرائعة حول كيفية استخدامها.

يعد NetTiers جيدًا جدًا لإنشاء DAL ثقيل وقوي، ونحن نستخدمه داخليًا للمكتبات وأطر العمل الأساسية.

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

كلتا التقنيتين غير مرنتين تمامًا للتغيير دون إعادة إنشاء الكود أو طبقة dbml.

ومع ذلك، فإن استخدام LINQ 2 SQL بشكل صحيح يعد حلاً قويًا تمامًا، وقد تبدأ في استخدامه للتطوير المستقبلي نظرًا لسهولة استخدامه، لكنني لن أتخلص من DAL الحالي الخاص بك - إذا لم يكن معطلاً. ..

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

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

أنا أستخدم LINQ to SQL في مشروع كبير إلى حد ما في الوقت الحالي (حوالي 150 جدولًا) وهو يعمل جيدًا بالنسبة لي.آخر ORM استخدمته كان IBatis وقد عمل بشكل جيد ولكنه استغرق الكثير من العمل القانوني لإنجاز تعييناتك.يعمل LINQ to SQL بشكل جيد للغاية بالنسبة لي وقد أثبت حتى الآن أنه سهل الاستخدام للغاية.هناك بالتأكيد بعض الاختلافات التي يتعين عليك التغلب عليها أثناء المرحلة الانتقالية، لكنني أوصي باستخدامها.

ملاحظة جانبية، لم أستخدم NetTiers أو أقرأ عنه مطلقًا، لذا لن أقلل من فعاليته، لكن LINQ إلى SQL بشكل عام أثبت أنه ORM قابل للتطبيق للغاية.

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

  • إعادة إنشاء آلاف الأسطر من التعليمات البرمجية في 3 مشاريع منفصلة
  • إعادة إنشاء مئات الإجراءات المخزنة

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

ثم جاء الضوء، NHibernate باعتباره ORM.من المؤكد أن لديها وقتًا متصاعدًا ولكن الأمر يستحق ذلك.هناك قدر كبير من الدعم لذلك، لذا إذا كان هناك شيء تحتاج إلى القيام به، فمن المرجح أنه تم القيام به من قبل.إنه مرن للغاية ويسمح لك بالتحكم في كل جانب منه ثم بعضه.لقد أصبح أيضًا أسهل وأسهل في الاستخدام.Fluent Nhibernate صاعد ويأتي كطريقة رائعة للتخلص من ملفات تعيين XML المطلوبة ويوفر NHibernate Profiler واجهة ممتازة لمعرفة ما يحدث خلف الكواليس لزيادة الكفاءة وإزالة التكرار.

لقد كان الانتقال من NetTiers إلى NHibernate مؤلمًا، ولكن بطريقة جيدة.لقد أجبرنا على الانتقال إلى بنية أفضل وإعادة تقييم الاحتياجات الوظيفية.قدمت NetTiers الكثير من رموز الوصول إلى البيانات، واحصل على هذا الكيان من خلال معرفه، واحصل على هذا الكيان الآخر من خلال مفتاحه الخارجي، واحصل على قائمة tlist وvlist لهذا وذاك، ولكن معظمها كان غير ضروري وغير مستخدم.NHibernate باستخدام مستودع عام ومستودعات مخصصة فقط عند الحاجة، مما يقلل من عدد الأطنان من التعليمات البرمجية غير المستخدمة ويزيد من سهولة القراءة والموثوقية.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top