using‌ توسط کامپایلر به try/finally ترجمه میشه و قسمت dispose رو در قسمت finally قرار میده. بنابراین اگر این وسط استثنایی رخ بده، حتما قسمت finally اجرا خواهد شد.

هیچ ایرادی نداره که حتی 10 کوئری متفاوت هم در یک متد صادر شوند. این business logic که می‌گن همینه. بسته به منطق تجاری که قرار است پیاده سازی شود،‌ شما هر تعداد کوئری که نیاز داشتید را فراخوانی کنید.
فقط بحث اینجا است که فایل code behind ، محل پیاده سازی Data access layer و همچنین محل تعریف هیچ نوع منطق تجاری نیست. این‌ها باید از فایل code behind دور شوند.  اینجا فقط محل استفاده نهایی از منطق تهیه شده است.

در ANSI C ،‌ متغیرها فقط ابتدای تابع (scope block) مجاز به تعریف هستند؛ و هر زمان که به دنبال تعریف متغیرها در ابتدای متدی گشتید یعنی هنوز حال و هوای ANSI C برقرار است.  اما از زمان سی++ به بعد خیر؛ هر چند کامپایلر با هر دو حالت مشکلی ندارد.
بحث تکمیلی در اینجا : (^)
به صورت خلاصه: از سی++ به بعد متغیرها را در نزدیکترین مکانی که اولین استفاده از آ‌نها صورت می‌گیرد تعریف کنید تا بهتر بدانید که به چه علتی تعریف شده. همچنین خیالتان هم راحت می‌شود که به اشتباه جای دیگری استفاده نشده یا نمی‌شود.

هر دو کوئری رو میشه تبدیل به یک کوئری کرد : SELECT Pnumber, UserLevel FROM listuser where blabla و اون وقت بهتر خواهد بود که از DataReader استفاده شود. البته نه در این متد.
و کسانی هم که نمی‌خواهند از ORM استفاده کنند، Wrappers خیلی خوبی بعد از دات نت 4 برای ADO.NET اومده. مطلب در موردش در سایت هست تحت عنوان Micro ORMs

همون،‌ مگر اینکه این «جنریتور»ها با چهارتا علامت تعجب به داد برسه و گرنه کمی صحبت کردن در مورد زیرساخت این‌ها کمی باعث سرگیجه میشه؛ خصوصا تفکر در مورد آن‌ها.

سلام؛ لطفا کامنت خارج از موضوعی را مطرح نکنید. چون حذف می‌شود. با تشکر.
جوابتون رو هم می‌تونید اینجا پیدا کنید: (^)

سلام؛ برای پیدا کردن لیست این موارد کلمه OPML را در سایت جاری جستجو کنید.

این رو برای کسانی نوشتم که می‌دونند با Reflector چطور باید رفتار کرد. چطور باید اطلاعات رو رمزنگاری کرد، چطور باید از SecureString استفاده کرد، چطور باید ردی در حافظه نذاشت. این فقط یک شروع بود ...

- شما تمام خواص عمومی (و حتی غیرعمومی) رو می‌تونید به کمک Reflection لیست کنید. نوع آن‌ها هم که مشخص است از جنس مثلا ICommand یا DelegateCommand هستند. بنابراین یافتن و لیست کردن خودکار Commands تعریف شده در یک ViewModel به این ترتیب امکان پذیر است.
- در حالت کلی برای مدیریت Commands فقط کافی است قسمت canExecute آن‌ها را مدیریت کنید (مثلا در delegate command معرفی شده در همین سری). اگر false برگرداند (مثلا بر اساس سطح دسترسی کاربر جاری)، خودبخود عنصر مرتبط با آن غیرفعال خواهد شد.

سلام؛ ممنون. شما لطف دارید.
این کتابچه در حقیقت شرح نوشتن یک برنامه بازی به کمک الگوی MVVM است. بد نیست ولی انتظار نداشته باشید که به صورت قدم به قدم چیزی را توضیح داده باشد. فقط شرح برنامه است.