بحث و گفتگو درباره MyFrameWork

[اوبالیت به بو]

سلام

این چیزی هست که تونستم تو مدت کوتاهی که با asp.net آشنا شدم بسازم.

اگر دوستان محبت کنن نقد کنن ممنون می شم.

[mehdi.mousavi]

سلام این چیزی هست که تونستم تو مدت کوتاهی که با ASP.NET آشنا شدم بسازم. اگر دوستان محبت کنن نقد کنن ممنون می شم.

سلام.
بدون مقدمه میرم سر اصل مطلب:


با وجود اینهمه Framework خوب Open source برای اینکار، دیگه امروزه نیازی نیست که کسی اینکارو خودش از صفر انجام بده. برخی از این پروژه ها عبارتند از SubSonic (http://www.subsonicproject.com/)، .NETTiers (http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1)، NHibernate (http://community.jboss.org/wiki/NHibernateforNET) و ... محصولاتی تجاری هم در این زمینه وجود دارند که یکی از بهترینهاشون LLBLGen Pro (http://www.llblgen.com/defaultgeneric.aspx) هستش. من خودم اینکارو شما رو کردم، منظورم درست کردن Framework ای برای خودم بود، اما اون زمانی که من اینکارو میکردم، ORM ای وجود نداشت یا همشون تو نسخه های Beta بودن و پر از ایراد و ... اما امروزه، اوضاع فرق میکنه...
اگر شماره یک رو نادیده بگیریم، (که حقیقتا نباید اینکارو کنیم)، حالا میریم سراغ کد شما. اولین ایرادی که به چشم من اومد، عدم استفاده از فایل web.config به شکل مناسب بودش... فرض کنید برنامه ای دارید (اینهایی که میگم رو تو سالیان گذشته بهش برخوردم و هیچکدوم خیالپردازی نیست) که باید به چند تا Data Source بطور همزمان متصل بشه و کاری رو انجام بده. تو چنین حالتهایی، کلاس DB شما و تعریف ConnectionString مربوطه، جدا دچار مشکل میشه. در واقع، کلاس DB شما، به MyConnectionString بشدت بند شده (Tightly Coupled) و این شما رو هنگام انجام در پروژه های واقعی، دچار مشکل خواهد کرد.
ایراد بعدی عدم Dispose کردن Object هایی هستش که IDisposable رو Implement کردن و یکی از مواردی که این مساله بعدا شما رو دچار مشکل میتونه کنه، عدم انجام اینکار روی Object های Database هستش. اولین مساله ای که ممکنه برنامه شما از اون عذاب بکشه، اختلالاتی هستش که میتونه توی مدیریت Connection Pooling دیده بشه. برای اینکه Connection Pooling بخوبی انجام بشه، شما موظف هستید که Object های Disposable رو حتما Dispose کنید.
از طرف دیگه شما یک BLL دارید، اما کدی که توش نوشتید متعلق به DALc هستش. CRUD ربطی به BLL نداره، اگرچه باید روی Business Logic Object ها کار کنه. من هیچگونه BLO ای در پروژه BLL شما ندیدم.

ایرادهای بسیار دیگه ای من تو این کد میبینم، اما حقیقتا فرصت توضیح دادن دونه به دونه اش رو ندارم. به برخی از اونها فقط سریع و سیر اشاره میکنم:


try...catch هایی که فقط خطا رو میگیرن و اونو rethrow میکنن.
عدم کنترل Transaction ها توسط .Framework
دادن دسترسی public به Object هایی که در DAL استفاده کرده اید.
استفاده از Untyped-DataSet ها (که خوبیها و بدیهایی داره).
قرار دادن DAL و کلاس DB در MyFrameWork.BLL namespace.
عدم وجود یک Factory Class برای تولید یک Instance از DAL.
عدم وجود لایه Facade.
و ...

موفق باشید.

[اوبالیت به بو]

بسیار ممنون. علت اینکه از FrameWork های دیگه استفاده نکردم این بود که باهاشون آشنا نیستم و اصلاً گوشم بهشون نخورده. من فقط با چند تا FrameWork تو PHP آشنا هستم که اون ها هم به کارم نیومدن.

دلیل پافشاری هم اینه که فعلا تو مرحله یادگیری هستم و می خوام خودم خلق کنم.

معایبی رو هم که شما فرمودین من بهشون اعتماد می کنم و تو همین تایپیک به رفع اون ها می پردازم.

[اوبالیت به بو]

1- عدم استفاده مناسب از فایل Web.Config جهت کار با Data Source های مختلف
2- قرار دادن DAL و کلاس DB در MyFrameWork.BLL namespace.
3- عدم وجود یک Factory Class برای تولید یک Instance از DAL
4- دادن دسترسی public به Object هایی که در DAL استفاده کرده اید
5- عدم کنترل Transaction ها توسط .Framework
6- استفاده اشتباه از لایه BLL و دخالت لایه DAL در BLL
7- عدم Dispose کردن Object هایی هستش که IDisposable رو Implement کردن
8- عدم وجود لایه Facade.
9- وجود try...catch هایی که فقط خطا رو میگیرن و اونو rethrow میکنن.
10- عدم کنترل Transaction ها توسط .Framework

[اوبالیت به بو]

دوستان اگر ممکن هست راجب به موضوع شماره 2 راه حل ارائه کنیم:


قرار دادن DAL و کلاس DB در MyFrameWork.BLL namespace


ممنون

[mehdi.mousavi]

دوستان اگر ممکن هست راجب به موضوع شماره 2 راه حل ارائه کنیم:

سلام.
راه حل؟ خوب کافیه دو namespace متفاوت برای این دو بخش در نظر بگیرید. BLO ها رو در MyCompany.MyApp قرار بدید و DAL رو در MyCompany.MyApp.Dal قرار بدید. منظورم فقط جداسازی Namespace ها بود، چون معمولا این کاری که شما کرده اید رو انجام نمیدن.

موفق باشید.

[Alireza_Salehi]

به علاوه مواردی که دوستان ذکر کردند موارد زیر رو هم در نظر بگیرید:
1. DataSet بسیار سرعت کمی داره و تا جائی که می تونید ازش استفاده نکنید، مخصوصا در پروژه های تحت وب. من شخصا استفاده از لیست های جنریک رو ترجیح میدم.(تعریف کلاس ها و ...)
2. با معرفی شدن LINQ و dbml و امکانات متعددی که ارائه کرده (از جمله امکان سفارشی سازی متدها و افزایش کارائی) پیشنهاد میکنم از LINQ استفاده کنید.
3.در مورد DAL هم به طور ساده : DAL مسئول اتصال و عملیات دیتابیس است وظیفه استفاده از DAL به عهده BLL است بنابراین کدهای داخل BLL رو به DAL انتقال بدید و در BLL صرفا از اونها استفاده کنید.
DAL کار خودش را انجام می دهد و نتیجه را به BLL اطلاع می دهد و BLL با توجه به نتیجه یا خروجی را نمایش می دهد یا پیام مناسبی صادر می کند.
4. یک قسمت log هم برای فریمورکتون اضافه کنید try catch ها بیهوده هستند اگر نمی گذاشتید هم خودشون throw می کردند

کلا برید به سمت استفاده از LINQ دیتاست قدیمی شده.

[اوبالیت به بو]

راه حل؟ خوب کافیه دو namespace متفاوت برای این دو بخش در نظر بگیرید. BLO ها رو در MyCompany.MyApp قرار بدید و DAL رو در MyCompany.MyApp.Dal قرار بدید. منظورم فقط جداسازی Namespace ها بود، چون معمولا این کاری که شما کرده اید رو انجام نمیدن.
منظور از راه حل یعنی آموزش درست استفاده کردن یا همون آموزش هستش. چون اگر کسی راه درست رو بلد بود قطعاً ازش استفاده می کرد، خودتون هم اشاره کردید که خیلی ها استفاده نمی کنن (چون بلد نیستم)
به هر حال ممنون از راهنماییتون.
آیا راه حل استفاده از فایل Web.Config و بخش section هست؟

کلا برید به سمت استفاده از LINQ دیتاست قدیمی شده. یه تفکری که وجود داره اینه که گفته میشه LINQ، ADO.NET و .. همه یک کار انجام می دن و اون هم دسترسی به داده. یعنی هدف فقط دسترسی داشتن به بانک داده ها هستش پس زیاد فرقی نمی کنه که درگیر تکنولوژی بشیم. آیا موافق این جمله هستید؟

[اوبالیت به بو]

BLO ها رو در MyCompany.MyApp قرار بدید و DAL رو در MyCompany.MyApp.Dal قرار بدید
جناب mehdi.mousavi (http://barnamenevis.org/forum/member.php?u=41233)،
BLO ها نباید در MyCompany.MyApp.BLL قرار بگیرند؟
و سوال :
در تعاریفی که خوندم اشاره شده که BLL فقط از متدهای DAL استفاده می کنه و منطق و شرط ها رو بررسی می کنه. پاراگراف دوم:


http://www.barnamenevis.org/forum/showpost.php?p=372261&postcount=7

من در قسمت MyFrameWork.BLL پوشه ای دارم به اسم Classes که Entity های جدول رو شامل می شن و ایرادی که در پروژه وجود داشت انجام کارهای مربوط به DAL در کلاس های این پوشه بود (CRUD)
آیا باید به این صورت تغییر بدم؟؟؟
1- انتقال پوشه MyFrameWork.BLL.Classes به بخش DAL. که میشه: MyFrameWork.DAL.Classes
2- انجام Validate ها (و از این قبیل) در MyFrameWork.BLL.Classes (تغییر ساختار BLO ها؟؟)
؟؟؟

[mehdi.mousavi]

جناب mehdi.mousavi (http://barnamenevis.org/forum/member.php?u=41233)،
BLO ها نباید در MyCompany.MyApp.BLL قرار بگیرند؟
و سوال :
در تعاریفی که خوندم اشاره شده که BLL فقط از متدهای DAL استفاده می کنه و منطق و شرط ها رو بررسی می کنه. پاراگراف دوم:


http://www.barnamenevis.org/forum/showpost.php?p=372261&postcount=7
من در قسمت MyFrameWork.BLL پوشه ای دارم به اسم Classes که Entity های جدول رو شامل می شن و ایرادی که در پروژه وجود داشت انجام کارهای مربوط به DAL در کلاس های این پوشه بود (CRUD)
آیا باید به این صورت تغییر بدم؟؟؟
1- انتقال پوشه MyFrameWork.BLL.Classes به بخش DAL. که میشه: MyFrameWork.DAL.Classes
2- انجام Validate ها (و از این قبیل) در MyFrameWork.BLL.Classes (تغییر ساختار BLO ها؟؟)
؟؟؟

سلام.
درسته. BLL، با استفاده از DAL و BLO ها، اطلاعات رو در RDBMS میتونه Persist کنه، یا اطلاعات مزبور رو از بانک بگیره و به UI انتقال بده. منطق کاری که می خواهید انجام بدید در BLL باید Encapsulate بشه. اما اینها به این معنی نیستش که همه اینها رو در یک Namespace قرار بدیم. DAL ربطی به BLO ها نداره، اگر چه اطلاعات رو توسط BLO ها اینور و اونور می بره. BLL جایی هستش که از Sub-System هایی که ساختیم برای اعمال Business Rule هامون استفاده می کنیم و از نظر من، قرار دادن BLO و DAL در یک Namespace، سنخیتی با هم نداره.

تو BLL مثلا متودی دارید تحت عنوان AddNewOrder که توش، با استفاده از BLO و DAL یک Order با شرایط از پیش تعیین شده، به بانک اضافه میکنه. حالا ممکنه اضافه شدن یک Order به معنای Insert کردن یک Record در جدول Order ها، یک یا چند رکورد در جدول OrderDetails و ... باشه که همه باید Transactional انجام بشه. این اضافه شدن ها رو، BLL با استفاده از Sub-System های دیگه انجام داده و کنترل میکنه. اما توی DAL، فقط می تونید یک Order اضافه کنید. می تونید یک OrderDetails اضافه کنید و ... یعنی DAL از ترکیب این جداول و منطق Business شما، آگاهی نداره.

موفق باشید.

[اوبالیت به بو]

DAL ربطی به BLO ها نداره، اگر چه اطلاعات رو توسط BLO ها اینور و اونور می بره. BLL جایی هستش که از Sub-System هایی که ساختیم برای اعمال Business Rule هامون استفاده می کنیم و از نظر من، قرار دادن BLO و DAL در یک Namespace، سنخیتی با هم نداره.

پس اشتباهی که در معماری صورت گرفته اینه که من طراحی رو از لایه DAL شروع کردم. و refrence رو از DAL به BLL منتقل کردم. در صورتیکه باید از به ترتیب از بالا به پایین صورت بگیره. یعنی BLL باید به DAL اضافه بشه.
درست گفتم؟

[Mostafa_Dindar]

سلام ،

اگر در مورد معماري چند لايه احتياج به يك مقاله خوب داريد كه به صورت گام به گام و خوانا به شما توضيح بده من مقالات زير رو به شما پيشنهاد ميكنم ( مايكروسافت هم اونا رو در سايت رسمي ASP.NET به عنوان يك منبع خوب براي شروع معرفي كرده ) :


Previous Series
Building Layered Web Applications with Microsoft ASP.NET 2.0 - Part 1 (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416) (2)
Building Layered Web Applications with Microsoft ASP.NET 2.0 - Part 2 (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=419) (3)
Building Layered Web Applications with Microsoft ASP.NET 2.0 - Part 3 (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=420) (4)
Custom Sorting with N-Layer Design Classes and the GridView (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=428) (5)

Current Series
N-Layered Web Applications with ASP.NET 3.5 Part 1: General Introduction (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=476) (6)
N-Layered Web Applications with ASP.NET 3.5 Part 2: Introducing the Validation Framework (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=477) (7)
N-Layered Web Applications with ASP.NET 3.5 Part 3: Advanced Validation Topics (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=478) (8)
N-Layered Web Applications with ASP.NET 3.5 Part 4: Sorting, Paging and Filtering (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=479) (9)
N-Layered Web Applications with ASP.NET 3.5 Part 5: Dealing with Concurrency (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=480) (10)
N-Layered Web Applications with ASP.NET 3.5 Part 6: Security (http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=481)



در اينجا يك نمايي از Reference ها رو ميبينيد :

http://imar.spaanjaars.com/Images/Articles/N-LayerDesign/References.jpg




http://imar.spaanjaars.com/Images/Articles/N-Layer_Design_Next_Version/A_Typical_Flow_of_Data_Through_All_Layers.gif

موفق باشيد

[Alireza_Salehi]

یه تفکری که وجود داره اینه که گفته میشه LINQ، ADO.NET و .. همه یک کار انجام می دن و اون هم دسترسی به داده. یعنی هدف فقط دسترسی داشتن به بانک داده ها هستش پس زیاد فرقی نمی کنه که درگیر تکنولوژی بشیم. آیا موافق این جمله هستید؟
قطعا مخالفم.

اولین و مهمترین نکته در انتخاب فریمورک سرعت تولید برنامه توسط فریمورک (RAD) و کارائی (Performance) هستش، فریمورک برای این ساخته میشه که کار های معمول رو ساده تر بشه انجام داد نه این که یک بار اضافی هم به سیستم تحمیل کنه
اگر فریمورک شما کند باشه :
1. هزینه سرور رو بالا میبره
بالا رفتن استفاده از رم سی پیو و غیره...
2. سرعت بارگذاری سایت رو پائین میاره
3. اثر منفی زیادی در کاربر استفاده کننده میزاره
4. بعدا مجبور می شید یک هزینه اضافی برای بهینه سازی آن کنید و در برخی موارد بازنویسی

LINQ و dbml شدیدا در موارد زیر بر DataSet و کلاس های ADO.NET برتری دارد:
1. سرعت
2. سهولت کد نویسی و خوانا تر بودن کد
3. قابلیت توسعه متد ها وکلاس ها به راحتی آب خوردن
4. قابلیت UPDATE و DELETE و INSERT بسیار بسیار ساده تر از ADO.NET


من چون شخصا درگیر بهینه سازی سیستم های تجاری (وب-ویندوز -ویندوز موبایل) بوده ام اکیدا توصیه میکنم حداقل استفاده را از دیتاست کنید. متد های دیتاست در هنگام اجرا بسیاری شرط ها و کارهای غیر ضرور را انجام می دهند. که اثر منفی در کارائی دارد.

در ضمن LINQ خطاهای برنامه نویس را خیلی کمتر می کند چون بسیار خوش دست تر و واضع تر کارها را انجام می دهد.

مزیت دیگر LINQ این است که می توانید دیتابیس را در کنار دیگر انواع IEnumerable استفاده کنید. که بسیاری از کد نویسی های طاقت فرسا را در چند خط خلاصه میکند.

[m.hamidreza]

مِن باب آشنایی با مزیت ها و معایب استفاده از LinQ در فریم ورک برادر "جون"دوستان لطف کنن نظرشون درباره لینک های ذیل بفرمایند:


Performance Comparisons LINQ to SQL / ADO / Csharp (http://www.codeproject.com/KB/linq/performance_comparisons.aspx)
Performance benchmarks for LINQ vs. SqlDataReader, DataSet - Selects: Part 1 (http://www.devtoolshed.com/content/performance-benchmarks-linq-vs-sqldatareader-dataset-selects-part-1)
Performance benchmarks for LINQ vs. SqlDataReader, DataSet - LINQ Compiled Queries: Part 2 (http://www.devtoolshed.com/content/performance-benchmarks-linq-vs-sqldatareader-dataset-linq-compiled-queries-part-2)

با تشکر.

[اوبالیت به بو]

سلام

کلاس ها رو یه تغییر کوچیک دادم.
این ساختار درست هست؟

یه سوال دارم:

می خوام سیستم قسمتی داشته باشه که Exeption ها رو Handle کنه. اما راهش رو بلد نیستم. میشه نحوه پیاده سازیش رو با مثال نوضیح بدید؟

[Alireza_Salehi]

مِن باب آشنایی با مزیت ها و معایب استفاده از LinQ در فریم ورک برادر "جون"دوستان لطف کنن نظرشون درباره لینک های ذیل بفرمایند:


Performance Comparisons LINQ to SQL / ADO / Csharp (http://www.codeproject.com/KB/linq/performance_comparisons.aspx)
Performance benchmarks for LINQ vs. SqlDataReader, DataSet - Selects: Part 1 (http://www.devtoolshed.com/content/performance-benchmarks-linq-vs-sqldatareader-dataset-selects-part-1)
Performance benchmarks for LINQ vs. SqlDataReader, DataSet - LINQ Compiled Queries: Part 2 (http://www.devtoolshed.com/content/performance-benchmarks-linq-vs-sqldatareader-dataset-linq-compiled-queries-part-2)

با تشکر.
Benchmark های دیگری هم هست که نتایج اونها تقریبا با اینها مشابه هستش، نکته اینه که متدهای لینک را میتوانید به راحتی با شرایط پروژه خودتان بنویسید و بهینه ترین راه را استفاده کنید. (مجبور به استفاده از متد های پیشفرض نیستید- دچار سختی های توسعه DataSet هم نمی شوید)

افزوده شدن Parallel رو هم فراموش نکنید.تاثیر عجیبی داره.

بعد از تغییر متد های مهم و افزایش کارائی آنها با همان سینتکس LINQ به کار خود ادامه می دهید.

در ضمن نکات و ترفندهایی هم در راستای تولید کوئری های بهینه تر و افزایش کارائی برای متد های پیشفرض موجود است.

بنده مدتی روی Performance نرم افزار در محیط های عملیاتی (ویندوز-موبایل-وب مبتنی بر SOA) و نه آزمایشگاهی کار کرده ام سهولت + کارئی LINQ بر ADO.NET می چربد.

این را هم باید عرض کنم در بحث خواندن داده ها و پر کردن کلاسها معمولا DataReader سریع ترین است- کد نویسی و خطا یابی بیشتری می طلبد- هر چند در مواردی LINQ سریع تر عمل میکند.

در محیط هایی که ترکیب داده های برنامه، دیتابیس و XML مورد نیاز است قطعا لینک بهترین است.

علاوه بر همه موارد فوق LINQ شدیدا زمان توسعه برنامه را کاهش می دهد.


بهترین گزینه ترکیب SP و dbml و DataReader است. بنده DataSet را در موارد کمی به کار می برم. طراحی صحیح برنامه در بسیاری موارد نیاز به دیتاست را از میان برمی دارد.


منابعی که جهت طراحی چند لایه در پست 12 معرفی شده است مربوط به زمانی است که LINQ در حالت بتا قرار داشته است . در حال حاظر که LINQ جواب خود را پس داده و بزودی نسخه تکمیل شده آن در C# 4 ارائه می شود و با توجه به روشها و متدولوژی های جدید تر C# 3.5 , 4 در زمینه کار با داده LINQ و موارد مربوط به آن انتخاب اول است.

[اوبالیت به بو]

من از این خیلی خوشم اومد:

http://forum.iranphp.org/Thread-%D8%AF%D8%B1%D8%A8%D8%A7%D8%B1%D9%87-MyFrameWork?highlight=myframework

[اوبالیت به بو]

نقل قول: بحث و گفتگو درباره MyFrameWork

[Mostafa_Dindar]

منابعی که جهت طراحی چند لایه در پست 12 معرفی شده است مربوط به زمانی است که LINQ در حالت بتا قرار داشته است . در حال حاظر که LINQ جواب خود را پس داده و بزودی نسخه تکمیل شده آن در C#‎ 4 ارائه می شود و با توجه به روشها و متدولوژی های جدید تر C#‎ 3.5 , 4 در زمینه کار با داده LINQ و موارد مربوط به آن انتخاب اول است.


اگرچه معتقدم درحال حاضر (يعني ASP.NET 3.5 , 4.0) ، لينك با سهولت و كارايي اي كه دارد انتخاب خوبي هست ، مقالات مرجوعي رو نه به عنوان يك جايگزين يا رقيب براي LINQ، بلكه براي آشنايي با مفاهيم در نظر بگيريد .
مفاهيم معماري چند لايه يكسان است ، تفاوتي ندارد كه از LINQ استفاد كنيد يا از ديگر ORM ها .

[mtaboy]

قطعا مخالفم.



LINQ و dbml شدیدا در موارد زیر بر DataSet و کلاس های ADO.NET برتری دارد:
1. سرعت
2. سهولت کد نویسی و خوانا تر بودن کد
3. قابلیت توسعه متد ها وکلاس ها به راحتی آب خوردن
4. قابلیت UPDATE و DELETE و INSERT بسیار بسیار ساده تر از ADO.NET



در ضمن LINQ خطاهای برنامه نویس را خیلی کمتر می کند چون بسیار خوش دست تر و واضع تر کارها را انجام می دهد.


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

[Behrouz_Rad]

من با مورد اول موافق نیستم .یعنی linq بخاطر استفاده کردن از رفلکشن به مراتب از ado کندتر هستش

برادر میشه بگی LINQ در کدام قسمت خودش از Reflection استفاده می کنه؟

[adinochestva]

به لینک زیر مراجعه شود :
http://stackoverflow.com/questions/766540/does-entity-framework-linq-to-sql-data-binding-use-reflection

[Alireza_Salehi]

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

لینک مزیت های زیادی دارد، ممکن است در شرایطی کندتر عمل کند ولی در مجموع تجربه من برتری LINQ را نشان می دهد.
این را هم در نظ بگیرید که ADO.NET منحصر به پایگاه داده است ولی
LINQ To SQL
LINQ To Object
LINQ To XML
LINQ To ADO.NET (http://msdn.microsoft.com/en-us/library/bb386977%28v=VS.100%29.aspx)
و....
یعنی در یک برنامه چند وجهی و پیچیده با یک ابزار می توان همه چیز را کنترل کرد.

در ضمن در پست قبلی هم عرض کردم در موقع خواندن داده ها هنوز هم DataReader سریع ترین است بنابراین تعصبی روی LINQ ندارم...

[Behrouz_Rad]

به لینک زیر مراجعه شود :
http://stackoverflow.com/questions/766540/does-entity-framework-linq-to-sql-data-binding-use-reflection
در اون لینک مطلب قابل استنادی پیدا نمی کنی. فردی فرض و گمان خودش رو بر مبنای یک تکه کد نوشته و بقیه هم در مورد اون نظر دادن و برخی اون رو رد کردن و یک نفر به MSDN ارجاعش داده و گفته که بر خلاف حرفی که ایجاد کننده تاپیک زده، L2S از IListSource و IBindingList در DataBinding استفاده می کنه و نیازی هم به ITypedList نداره.

موفق باشید.

[Mostafa_Dindar]

برادر میشه بگی LINQ در کدام قسمت خودش از Reflection استفاده می کنه؟

طبق گفته هاي Scott Guttrie (http://weblogs.ASP.NET/scottgu/archive/2007/05/15/new-orcas-language-feature-anonymous-types.aspx?CommentPosted=true) در LINQ هنگام Anonymous Types Data Binding از Reflection استفاده ميكند .

ولي به اينكه اين Reflection چقدر در كارايي تاثير گذار خواهد بود اشاره نكرده . در هر صورت استفاده LINQ اونقدر مزاياها دارد كه اين مورد قابل اغماض هست .

[Behrouz_Rad]

طبق گفته هاي Scott Guttrie در LINQ هنگام Anonymous Types Data Binding از Reflection استفاده ميكند .

درست نخوندی. این مورد ارتباطی با Reflection در LINQ ندارد. اصولاً هر وقت که Anonymous Type ایجاد کنی، برای دسترسی به Property های اون از Reflection استفاده میشه. چه از طریق LINQ باشه و چه مستقیماً ایجاد کنی.

موفق باشید.

[adinochestva]

linq2sql در بعضی موارد از MethodInfo استفاده می کند به عنوان مثال برای فراخوانی function های db
و لینکی هم که بنده ارجاع دادم به همین موضوع می پردازه.