آیا تکنولوژِی LINQ to SQL مرد ؟؟ و entity جاگزین اون شده؟

[r4hgozar]

سلام دوستان.
من تو منبعی خوندم که تکنولوژی LINQ مرده و ENTITY جایگزین اون شده.

میشه راهنمایی کنین که الان جدید ترین تکنولوژی چیه برای ارتباط با پایگاه داه؟

[hosseinbarnamenevis]

سلام
اره منم سال قبل این مطلب رو خوندم
نه اینکه مرده باشه اما دیگه پیشرفت داده نمیشه و به مرور دیگه پشتیبانی نمیشه
حالا بهترین جایگزینشو نمیدونم دیگه :)

[r4hgozar]

کس دیگه این نیست راهنمایی کنه؟

[behi1ty]

سلام
من تو كارم با ديتا هاي زيادي سر كار دارم و شركت ما پشتيباني بانك ها را در اختيار داره
جالبه بدونيد با 50هزار ركورد وقتي روش ADO و EF تست كرديم ديدم سرعت ADO خيلي بيشتر از EF است و به روش قبل ادامه داديم
و الان هم تو تمام پروژه ها از ADO استفاده مي كنيم
اما EF راحته و خيلي سريع كار برنامه نويس و راه مي اندازه اما كار كاربر و به مراتب به سخت تر ميكنه
نظر شخصي من اينه كه تو پروژه هاي كوچك مي شه از EF استفاده كرد اما بزرگ شايد ديوانگي باشد

[علي فتحي]

من با انتي تي يك برنامه كوچك طراحي كردم .مشكل كار اين بود ويوهاي تو درتورو پشتيباني نميكنه.اجبارا اومدم به لينك تغييرش دادم. ايراد زياد داره

[sara_traveler]

منظورتون از ado روش ado.net entity هست که میگین سرعتش بالاتره؟

اخه امکان نداره سرعت ado بالاتر باشه چون ef هم تراز با روسیجر ها کار میکنه پس طبیعتا سرعت خیلی خوبی داره
شما اگر فیلم ها اموزش زبان اصلی هم نگاه کنید همین مطلب میگه
اگر سرعت ن بالاتر بود چرا دیگه بیان همچین چیزی بیارن این همه وقت براش بذارن
پس منطقی نیست

[linux]

منظورتون از ado روش ado.net entity هست که میگین سرعتش بالاتره؟

اخه امکان نداره سرعت ado بالاتر باشه چون ef هم تراز با روسیجر ها کار میکنه پس طبیعتا سرعت خیلی خوبی داره
شما اگر فیلم ها اموزش زبان اصلی هم نگاه کنید همین مطلب میگه
اگر سرعت ن بالاتر بود چرا دیگه بیان همچین چیزی بیارن این همه وقت براش بذارن
پس منطقی نیست
در مورد ORM ها مطالعه کنید.

[sara_traveler]

مطالعه کردم و فیلم های زبن اصلیشم گوش دادم
orm (object relation mapping)
که یکی از روش های اون همین ef هست

[behi1ty]

منظورتون از ado روش ado.net entity هست که میگین سرعتش بالاتره؟

اخه امکان نداره سرعت ado بالاتر باشه چون ef هم تراز با روسیجر ها کار میکنه پس طبیعتا سرعت خیلی خوبی داره
شما اگر فیلم ها اموزش زبان اصلی هم نگاه کنید همین مطلب میگه
اگر سرعت ن بالاتر بود چرا دیگه بیان همچین چیزی بیارن این همه وقت براش بذارن
پس منطقی نیست
سلام
دوست عزيز شما مي خواهيد يك سري ركورد و تو برنامه خودتون نشون بديد
براي اين كار بايد از دستور SELECT استفاده كنيد درسته؟؟؟؟؟؟؟
شما اين Select تو ADO خودت مي نويسي و مستقيم به SQL مي دي و اطلاعات و بر مي گردونه
اما تو EF اطلاعات شما را تبديل مي كنه به SELECT بعد اطلاعات و بر مي گردونه كه در حجم بالا به زمان بر است
تكنولوژي EF براي راحتي برنامه نويس است نه بيشتر كردن سرعت كه اگر اين بود ماكروسافت ADO و ديگه پشتيباني نمي كرد

در كل اين يك منطق است نه فيلم آموزشي و كتاب و .....

[sara_traveler]

اگر مشکل شما فقط select هست که خوب میشه در برنامه اطلاعات به همون روش قدیم نمایش داد

اما در بقیه قسمت ها چی
مثل insert delete update serch,....

ببینید بخاطر یک دستور Select ما نباید بیایم این روش که واقعا راحتر سریع تر هست بذاریم کنار و بگیم استفاده از این روش دیوانگی هست و بقیه رو هم از یادگیری این روش منصرف کنیم
من خودمم تو برنامه هام Select به روش قدیم هست اونم بخاطراینکه دیدم با این روش در گرید جانوس به مشکل خوردم اما بقیه با ef نوشتم
و واقعا تو سرعت برنامه نویسی تاثیر داره

[linux]

سلام
دوست عزيز شما مي خواهيد يك سري ركورد و تو برنامه خودتون نشون بديد
براي اين كار بايد از دستور SELECT استفاده كنيد درسته؟؟؟؟؟؟؟
شما اين Select تو ADO خودت مي نويسي و مستقيم به SQL مي دي و اطلاعات و بر مي گردونه
اما تو EF اطلاعات شما را تبديل مي كنه به SELECT بعد اطلاعات و بر مي گردونه كه در حجم بالا به زمان بر است
تكنولوژي EF براي راحتي برنامه نويس است نه بيشتر كردن سرعت كه اگر اين بود ماكروسافت ADO و ديگه پشتيباني نمي كرد

در كل اين يك منطق است نه فيلم آموزشي و كتاب و .....

تو ado.net شما مستقیم دستورات sql را با sqlcommand به سمت sqlserver می فرستید درست، و جواب را بصورت شی از کلاس SqlDataReader در اختیار دارید که با خواندن از این کلاس اطلاعات مورد نظر را پردازش می کنید و در قالب یک لیستی از اشیای مورد نظر ذخیره می کنید. در EF هم همین اتفاق می افتند بجای اینکه اون دستور سلکت ، اینزرت ،‌آپدیت یا دلیت را مستقیم به sqlcommand بدهید EF دستور معادل sql اش را از روی linq برای شما می سازد بعد به sqlcommand می دهد و بقیه ماجرا. یعنی EF خودش از Ado.net کمک می گیرد. در اکثر مواقع هم کندی سرعت هم قابل چشم پوشی هست.

[behi1ty]

تو ado.net شما مستقیم دستورات sql را با sqlcommand به سمت sqlserver می فرستید درست، و جواب را بصورت شی از کلاس SqlDataReader در اختیار دارید که با خواندن از این کلاس اطلاعات مورد نظر را پردازش می کنید و در قالب یک لیستی از اشیای مورد نظر ذخیره می کنید. در EF هم همین اتفاق می افتند بجای اینکه اون دستور سلکت ، اینزرت ،‌آپدیت یا دلیت را مستقیم به sqlcommand بدهید EF دستور معادل sql اش را از روی linq برای شما می سازد بعد به sqlcommand می دهد و بقیه ماجرا. یعنی EF خودش از Ado.net کمک می گیرد. در اکثر مواقع هم کندی سرعت هم قابل چشم پوشی هست.
منم همين و عرض كردم
اما اصلا نمي توني از سرعت چشم پوشي كني
من عرض كردم با ازلاعات بانك سر و كار داريم و خيلي خيلي سرعت مهمهيه مثال ساده مي زنم ركورد بعضي از جداول ما اينقدر بالاست كه
براي بك آپ زماني 7-8 ساعت وقت نياز داريم
دوست گرامي من نمي گم كسي ياد نگيره من خودم اين روش و بلدم و كار كردم و مطالعه هم مي كنم
اما اينكه تكنولوژي جديد بهترينه اشتباه است
شما اگر اطلاعات براي INSERT O UPDATE O DELETE اگر بخواي به صورت حرفه اي كار كني بايد براي هر كردم اينا يك SP داشته باشي چون هم امنيت بالاتره
هم سرعتش بيشتره و هم تغييراتش راحت تره و كلا اصولي تره(البته از نظر ما) نظر شما مهم تره
موفق باشد

[linux]

منم همين و عرض كردم
اما اصلا نمي توني از سرعت چشم پوشي كني
من عرض كردم با ازلاعات بانك سر و كار داريم و خيلي خيلي سرعت مهمهيه مثال ساده مي زنم ركورد بعضي از جداول ما اينقدر بالاست كه
براي بك آپ زماني 7-8 ساعت وقت نياز داريم
دوست گرامي من نمي گم كسي ياد نگيره من خودم اين روش و بلدم و كار كردم و مطالعه هم مي كنم
اما اينكه تكنولوژي جديد بهترينه اشتباه است
شما اگر اطلاعات براي INSERT O UPDATE O DELETE اگر بخواي به صورت حرفه اي كار كني بايد براي هر كردم اينا يك SP داشته باشي چون هم امنيت بالاتره
هم سرعتش بيشتره و هم تغييراتش راحت تره و كلا اصولي تره(البته از نظر ما) نظر شما مهم تره
موفق باشد
در EF هم می تونید از sp ها استفاده کنید. برای crud. اتفاقا دیتابیسی هم که من باهاش سرو کار دارم دیتابیس بانک هست شاید به اندازه دیتابیس شما حجیم نباشه. دور و بره ۲۰۰گیگابایت هست دیتای ما. با EF هم چندتا پروژه کار کردیم مشکلی نداشتیم تا حالا یعنی کندی سرعتش آنقدری نبود که کاربرها ابراز ناراحتی کنند یا شایدهم عادت کردند!
در مورد تکنولوژی جدید هم بله حق با شما هست همیشه بهترین نیست ولی orm ها خیلی وقت هست که هستند.
راستی در مورد dapper.net مطالعه کنید یک میکرو orm هست که خیلی سریع هست بعضی کارها را راحتر میکنه. سرعتش هم خیلی به ado.net نزدیکتره.

[behi1ty]

در EF هم می تونید از sp ها استفاده کنید. برای crud. اتفاقا دیتابیسی هم که من باهاش سرو کار دارم دیتابیس بانک هست شاید به اندازه دیتابیس شما حجیم نباشه. دور و بره ۲۰۰گیگابایت هست دیتای ما. با EF هم چندتا پروژه کار کردیم مشکلی نداشتیم تا حالا یعنی کندی سرعتش آنقدری نبود که کاربرها ابراز ناراحتی کنند یا شایدهم عادت کردند!
در مورد تکنولوژی جدید هم بله حق با شما هست همیشه بهترین نیست ولی orm ها خیلی وقت هست که هستند.
راستی در مورد dapper.net مطالعه کنید یک میکرو orm هست که خیلی سریع هست بعضی کارها را راحتر میکنه. سرعتش هم خیلی به ado.net نزدیکتره.
درسته دوت عزيز EF هم اين امكانات و داره منم نگفتم كلا بده يا كسي ياد نگيره
من خودم با EF پروژه نوشتم اما كوچيك
شما ديتاي خودتون و با ADO بنويسيد اون وقت متوجه فرق سرعت مي شين
ORM ها هم خودم دنبالش نرفتم اما هم كارم كه بررسي كرده مي گفت ADO بهتره هم لحاظ سرعت هم برنامه نويسي
چرا شو نمي دونم
شايد چون ما براي خودم كلاس هاي از قبل نوشته شده داريم براي همين با ado راحت تريم

[علی فتحی]

سلام منم تجربه شخصی خودم.من برنامه نویس ماهری نیستم نظر بدم.ولی یک برنامه انبارداری نوشتم .تقریبا 6000 محموله توش ثبت کردم و تو یک دیتا کرید نشون میدم.
1. با ویزاردکارکردم سرعتش بد نیست.
2.ادو یکم سرعتش بالاتره
3.entity کد نویسی راحت .و کاراتره ولی سرعتش بازم پایینتر
4.اخرید سر تغییر دادم به LINQ .فقط هنگام لود سرعتش نسبت به ادو پایینه و لی خدایی بدون ایراده لینک.حسن اون نسبت به انتی تی اینه حتی کوریهای بدون کلید اصلی رو هم قبول میکنه
توی انتی تی برای مشتری و میزان ورود یک کوری ساختم . تو انتی تی گاهی خودبخود دیتاگرید خالی نشون داده میشد.با تغییر به لینک حل شده
حالا برنامه حسابداریم هم با لینک بدون ایراد و خیلی خوب کار میکنه
وصلام

[EhsanAvr]

نسبت به تجربیاتی که داشتم این چند تا نکته به ذهنم میرسه:

linq 2 sql سرعتش نسبت به ef و ado.net کمتره و حتی اگه تعداد کوئری ها زیاد باشه (برای برنامه های تحت وب) سی پی یوی سرور شدیدا درگیر میشه.اما من هنوز هم در پروژه های کوچک ازش استفاده می کنم چون راه اندازی و پیاده سازی اون نسبت به روش های دیگه سریعتر و ساده تره

برای پروژه های بزرگ بهتره از ef استفاده کنید.چون کدتون خیلی تمیز و بدون نقص میشه و عمل بروزرسانی و تغییرات در پروژه به سادگی انجام میشه.سرعتش هم مناسبه.
برای پروژه های خیلی بزرگ حتما باید از ado.net استفاده کنید.مثلا برای پروژه ای که در ساعت نزدیک 2 میلیون کوئری به سمت دیتابیس ارسال می شد و تعداد رکوردهای هر جدول پایگاه داده بیش از 1 میلیون رکورد بود ابتدا با ef پیاده سازی کرذم که بعد از یک هفته از بس فشار به سرور زیاد بود که میخواستم یک سرور جدید با دو برابر قیمت سرور قبلی بخرم اما وقتی همین پروژه رو با ado.net پیاده سازی کردم الان روی همون سرور قبلی به خوبی داره کار میکنه.
یادتون نره اگه میزان استفاده منابع سرور و سرعت و کارایی پروژه براتون مهمه حتما برای تمام عملیات دیتابیسی حتی عملیات select از stored producer استفاده کنید و دیتابیستون رو به خوبی ایندکس گذاری کنید.