ج#:ماذا تستخدم أيضًا إلى جانب DataSet
https://stackoverflow.com/questions/18533
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
لقد وجدت نفسي غير راضٍ بشكل متزايد عن نموذج DataSet/DataTable/DataRow في .Net، ويرجع ذلك في الغالب إلى أنه غالبًا ما يكون أكثر تعقيدًا ببضع خطوات مما أريد فعله حقًا.في الحالات التي أكون فيها ملزمًا بعناصر التحكم، تكون مجموعات البيانات مناسبة.لكن في حالات أخرى، يبدو أن هناك قدرًا لا بأس به من العبء العقلي.
لقد لعبت قليلاً مع SqlDataReader، ويبدو أن هذا جيد للرحلات البسيطة من خلال التحديد، لكنني أشعر أنه قد تكون هناك بعض النماذج الأخرى الكامنة في .Net والتي من المفيد معرفة المزيد عنها.أشعر أن كل المساعدة التي أجدها في هذا الشأن تستخدم DataSet افتراضيًا.ربما يكون هذا وDataReader هما أفضل الخيارات حقًا.
أنا لا أبحث عن أفضل/أسوأ تفصيل، فقط أشعر بالفضول حول خياراتي وما هي التجارب التي مررت بها معهم.شكرًا!
- اريك سيبل
المحلول
منذ ظهور .NET 3.5، استخدمت LINQ حصريًا.انها حقا جيدة.لا أرى أي سبب لاستخدام أي من تلك العكازات القديمة بعد الآن.
على الرغم من روعة LINQ، أعتقد أن أي نظام ORM سيسمح لك بالتخلص من هذا العبث.
نصائح أخرى
لقد ابتعدنا عن مجموعات البيانات وقمنا ببناء كائنات ORM الخاصة بنا بشكل فضفاض CSLA.يمكنك إنجاز نفس المهمة باستخدام DataSet أو LINQ أو ORM ولكن إعادة استخدامها (وجدنا) أسهل كثيرًا."رمز أقل يجعل المزيد من السعادة".
لقد سئمت DataSets في .Net 1.1، على الأقل قاموا بتحسينها بحيث لا تتباطأ بشكل كبير بالنسبة للمجموعات الكبيرة بعد الآن.
لقد كان دائمًا نموذجًا منتفخًا إلى حد ما - لم أر العديد من التطبيقات التي تستخدم معظم ميزاته.
كان SqlDataReader جيدًا، لكنني اعتدت أن أقوم بتغليفه في ملف IEnumerable<T> حيث كان T عبارة عن تمثيل مكتوب لصف البيانات الخاص بي.
Linq هو بديل أفضل بكثير في رأيي.
لقد تم استخدام كائنات نقل البيانات نمط (في الأصل من عالم Java، على ما أعتقد)، مع SqDataReader لملء مجموعات DTOs من طبقة البيانات لاستخدامها في طبقات أخرى من التطبيق.إن DTOs نفسها عبارة عن فئات بسيطة وخفيفة الوزن للغاية وتتكون من خصائص تحتوي على get/sets.يمكن تسلسلها/إلغاء تسلسلها بسهولة، واستخدامها لربط البيانات، مما يجعلها مناسبة تمامًا لمعظم احتياجات التطوير الخاصة بي.
أنا معجب كبير ب دون سرعة الصوت.يمكن لملف Batch/CMD المكتوب جيدًا إنشاء نموذج كائن كامل لقاعدة البيانات الخاصة بك في دقائق؛يمكنك تجميعه في ملف DLL الخاص به واستخدامه حسب الحاجة.نموذج رائع، أداة رائعة.يجعل الموقع الأمر يبدو وكأنه صفقة ASP.NET، ولكنه بشكل عام يعمل بشكل رائع في أي مكان تقريبًا إذا كنت لا تحاول استخدام إطار عمل واجهة المستخدم الخاص به (والذي أشعر بخيبة أمل إلى حد ما) أو أدوات الإنشاء التلقائي على مستوى التطبيق .
للتسجيل، إليك نسخة من الأمر الذي أستخدمه للتعامل معه (حتى لا تضطر إلى محاربته بشدة في البداية):
sonic.exe generate /server [servername] /db [dbname] /out [outputPathForCSfiles] /generatedNamespace [myNamespace] /useSPs true /removeUnderscores true
هكذا يفعل في كل مرة...ثم أنشئ ملف DLL من هذا الدليل - وهذا جزء من مشروع NAnt، تم إطلاقه بواسطة CruiseControl.NET - وننطلق بعيدًا.أنا أستخدم ذلك في WinForms، وASP.NET، وحتى في بعض الأدوات المساعدة لسطر الأوامر.يؤدي هذا إلى إنشاء أقل عدد من التبعيات وأكبر قدر من "قابلية النقل" (بين المشاريع ذات الصلة، على سبيل المثال).
ملحوظة
ما ورد أعلاه عمره الآن أكثر من عام.بينما لا أزال أحمل ولعًا كبيرًا في قلبي بـ SubSonic، فقد انتقلت إلى LINQ-to-SQL عندما أتمتع برفاهية العمل في .NET 3.5.في .NET 2.0، ما زلت أستخدم SubSonic.لذا فإن نصيحتي الرسمية الجديدة تعتمد على إصدار النظام الأساسي.في حالة .NET 3+، انتقل إلى الإجابة المقبولة.في حالة .NET 2.0، استخدم SubSonic.
تعد مجموعات البيانات رائعة للعروض التوضيحية.
لا أعرف ماذا أفعل بواحدة إذا جعلتني أستخدمها.
أستخدم ObservableCollection
ثم مرة أخرى أنا في مساحة تطبيقات العميل، WPF وSilverlight.لذا فإن تمرير مجموعة بيانات أو جدول بيانات من خلال الخدمة هو ...إجمالي.
تتميز قارئات البيانات بالسرعة، نظرًا لأنها عبارة عن دفق أمامي فقط لمجموعة النتائج.
لقد استخدمت DataSets المكتوبة وغير المكتوبة، وDataViewManagers، وDataViews، وDataTables، وDataRows، وDataRowViews، وأي شيء يمكنك فعله بالمكدس منذ ظهوره لأول مرة في مشاريع مؤسسية متعددة.استغرق الأمر مني بعض الوقت للتعود على كيفية عمل السماح به.لقد قمت بكتابة مكونات مخصصة تستفيد من المكدس لأن ADO.NET لم يعطني ما أحتاجه حقًا.يقوم أحد هذه المكونات بمقارنة مجموعات البيانات ثم يقوم بتحديث مخازن الواجهة الخلفية.أعرف حقًا كيف تعمل كل هذه العناصر بشكل جيد وأولئك الذين رأوا ما قمت به منبهرون جدًا لأنني تمكنت من تجاوز ذلك ويشعرون أنه كان مفيدًا فقط للاستخدام التجريبي.
أستخدم ربط ADO.NET في Winforms وأستخدم أيضًا الكود في تطبيقات وحدة التحكم.لقد تعاونت مؤخرًا مع مطور آخر لإنشاء ORM مخصص استخدمناه مقابل نموذج بيانات مجنون تم إعطاؤه لنا من مقاولين لا يشبهون مخازن البيانات العادية لدينا.
لقد بحثت اليوم عن بديل لـ ADO.NET ولا أرى أي شيء يجب أن أحاول تعلمه بجدية لاستبدال ما أستخدمه حاليًا.
أستخدمها على نطاق واسع ولكني لا أستفيد من أي من الميزات "المتقدمة" التي كانت Microsoft تدفعها بالفعل عندما ظهر إطار العمل لأول مرة.أنا أستخدمها بشكل أساسي كقوائم جداول التصنيف، والتي أجدها مفيدة تمامًا.
لم أر نتائج جيدة عندما حاول الأشخاص إنشاء مجموعات بيانات مكتوبة معقدة، أو حاولوا بالفعل إعداد علاقات المفاتيح الخارجية بين الجداول باستخدام مجموعات البيانات.
بالطبع، أنا واحد من الأشخاص الغريبين الذين يفضلون DataRow على مثيل كائن الكيان.
قبل الربط، استخدمت DataReader لملء قائمة كائنات المجال المخصص الخاصة بي، ولكن بعد نشر الرابط كنت أستخدم L2S لملء كيانات L2S، أو L2S لملء كائنات المجال.
بمجرد أن أحصل على مزيد من الوقت للتحقيق، أظن أن كائنات Entity Framework ستكون الحل المفضل الجديد لدي!
من المحتمل أن يكون اختيار أداة ORM حديثة ومستقرة ومدعومة بشكل نشط هو أكبر دفعة منفردة للإنتاجية يمكن أن يحصل عليها أي مشروع متوسط الحجم والتعقيد.إذا كنت تستنتج أنه يتعين عليك تمامًا، تمامًا، كتابة DAL وORM الخاصة بك، فمن المحتمل أنك تفعل ذلك بشكل خاطئ (أو أنك تستخدم قاعدة البيانات الأكثر غموضًا في العالم).
إذا كنت تقوم بإنشاء مجموعات بيانات أولية وصفوف وما إلى ذلك، فاقضِ يومًا في تجربة ORM وستندهش من مدى زيادة إنتاجيتك دون بذل كل الجهد المبذول في تعيين الأعمدة إلى الحقول أو التعبئة طوال الوقت كائنات أوامر Sql وجميع القفزات الأخرى التي مررنا بها جميعًا ذات مرة.
أحبني إلى حد ما دون سرعة الصوت، على الرغم من أنه بالنسبة للمشاريع الصغيرة الحجم جنبًا إلى جنب مع العروض التوضيحية/النماذج الأولية، أجد أن Linq to Sql مفيد جدًا أيضًا.أنا أكره EF بشغف بالرغم من ذلك.:ص
لقد استخدمت DataSets المكتوبة لعدة مشاريع.إنهم يصممون قاعدة البيانات بشكل جيد، ويفرضون قيودًا على جانب العميل، وبشكل عام يمثلون تقنية قوية للوصول إلى البيانات، خاصة مع التغييرات في .NET 2.0 باستخدام TableAdapters.
تحظى مجموعات البيانات المكتوبة بسمعة سيئة من الأشخاص الذين يحبون استخدام كلمات عاطفية مثل "منتفخة" لوصفها.سأوافق على أنني أحب استخدام مخطط O/R جيد أكثر من استخدام DataSets؛يبدو من الأفضل استخدام الكائنات والمجموعات بدلاً من DataTables وDataRows وما إلى ذلك.ولكن ما وجدته هو أنه إذا كنت لا تستطيع أو لا ترغب في استخدام مخطط O/R لأي سبب من الأسباب، فإن DataSets المكتوبة هي خيار قوي وجيد وسهل الاستخدام بدرجة كافية وسيوفر لك 90% من فوائد مخطط O/R.
يحرر:
يقترح البعض هنا أن DataReaders هو البديل "السريع".ولكن إذا كنت تستخدم Reflector لإلقاء نظرة على الأجزاء الداخلية لـ DataAdapter (التي يتم ملء DataTables بها)، فسترى أنه يستخدم... DataReader.مجموعات البيانات المكتوبة يمكن تحتوي على مساحة ذاكرة أكبر من الخيارات الأخرى، ولكنني لم أر بعد التطبيق الذي يُحدث فيه هذا فرقًا ملموسًا.
استخدم أفضل أداة لهذا المنصب.لا تتخذ قرارك على أساس كلمات عاطفية مثل "فظيع" أو "متضخم" والتي ليس لها أي أساس واقعي.
لقد قمت فقط بإنشاء كائنات الأعمال الخاصة بي من البداية، ولم أستخدم DataTable تقريبًا ولا سيما DataSet بعد الآن، باستثناء ملء كائنات الأعمال في البداية.تتمثل مزايا إنشاء مجموعة خاصة بك في قابلية الاختبار وأمان الكتابة والذكاء وقابلية التوسعة (حاول الإضافة إلى مجموعة بيانات) وسهولة القراءة (إلا إذا كنت تستمتع بقراءة أشياء مثل Convert.ToDecimal(dt.Rows[i]["blah"].ToString() )).
إذا كنت أكثر ذكاءً، لكنت سأستخدم أيضًا إطار عمل ORM وDI التابع لجهة خارجية، لكنني لم أشعر بالحاجة إلى ذلك بعد.أقوم بالكثير من المشاريع الصغيرة الحجم أو الإضافات إلى المشاريع الأكبر.
لا أستخدم مجموعات البيانات مطلقًا.إنها كائنات كبيرة ثقيلة الوزن يمكن استخدامها فقط (كما أشار أحد الأشخاص هنا) في "البرامج التجريبية".هناك الكثير من البدائل الرائعة المعروضة هنا.
