SqlDataSource مقابل ObjectDataSource

Question

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

أن يكون أكثر وضوحا:

متى يجب استخدام SqlDataSource أو ObjectDataSource?

كيف تحفز الاختيار ؟

Answer 1

مجرد وجود SQLDataSource هي صحيحة تماما ، إذا كان مجرد عرض النموذج الأولي ، أو سريعة الإختراق.انها سريعة, فإنه من السهل انها تعمل فقط و يعطيك النتائج التي تحتاج إليها.

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

كما يقول المثل - يمكنك حل أي شيء إلى حد كبير في علوم الكمبيوتر من طبقة واحدة أكثر من المراوغة (أو التجريد) - نفس حاصل هنا.

بالتأكيد:يمكنك الذهاب مباشرة إلى قاعدة البيانات, و في الأول و لأول التكرار ، ربما (ربما) أسرع طريقة.ولكن في المدى الطويل ، عندما تم بناء التطبيق على الماضي, انها عادة ما تكون سريعةو القذرة الطريقة - تكلفة صيانة, تكلفة الصيانة التكلفة والجهد اللازمين لتغيير وفقا الخاص بك و احتياجات العملاء الخاصة بك سوف تنمو بسرعة ، بسرعة'n'dirty الحل لا تبدو كبيرة جدا بعد الآن ، من حيث الجهد.

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

مارك

Answer 2

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

إذا كنت تسير في هذا الطريق، والخلط SQLDataSource وObjectDataSource يمكن أن يؤدي إلى الارتباك من قبل المطور المقبل لالتقاط المشروع. في هذه الحالة، وأنا العصا مع ObjectDataSource من أجل التناسق التعليمات البرمجية.

إذا لم يكن لديك طبقة رجال الأعمال وهي مجرد ضرب SQL مباشرة - استخدام SQLDataSource. بلدي تفضيل شخصي هو أن كل من التعليمات البرمجية SQL الخاصة بك ينبغي أن يكون في الأعمال التجارية أو البيانات طبقة، وبسبب كدت أبدا استخدام SQLDataSource.

Answer 3

وإذا كان يمكنك تطبيق كود طبقة عملك في إجراء مخزن وعلى نحو أفضل لاستخدام SQLDataSource

Answer 4

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

وهدفي على المدى الطويل هو إعادة كتابة التطبيق من الألف إلى الياء باستخدام أداة النمذجة ورمز مولد التجاري. إذا كنت تنوي استخدام objectdatasource أنا أوصي العثور على النمذجة أداة جيدة يتضمن مولد رمز مرونة.