صالح باقری صالح باقری
نظرات مطالب
سازگار سازی EFTracingProvider با EF Code first
مدتهاست که EF رو پیگیری میکنم ولی هنوز در مورد پروژه خودم به نتیجه ای نرسیدم.

پروژه ای که من دارم دیتابیس آن کاملاً ساخته شده و بر اساس دیتابیس، کلاسهای مرتبط با آن (BLL) نیز نوشته شده است. ولی کلاس‌های DAL رو ننوشتم تا اینکه با EF آشنا شدم.

میخواستم ببینم که اگه از DB First استفاده کنم چطور میتونم از کلاسهای نوشته شده قبل استفاده کنم؟ یا چطور میتونم جداول رو با کلاسهایی که خودم نوشتم مرتبط کنم؟ کلا اینکار پیشنهاد میشه یا خیر؟

اگه از CodeFirst استفاده کنم، تکلیف Db طراحی شده خودم چی میشه؟ چون دیتابیسی که EF ایجاد میکنه رو اصلاً نمیپسندم.

در کل آیا EF روشی برای ارتباط Code First و Db First داره؟

آیا با اینهمه کدهای پیچیده ای که EF ایجاد میکنه میشه ازش در پروژه‌های وب بزرگ که ترافیک سنگینی دارند استفاده کرد؟

در کل نظر خود شما چی هست؟
‫۱۲ سال و ۳ ماه قبل، یکشنبه ۲۲ مرداد ۱۳۹۱، ساعت ۰۸:۳۲
مجتبی کاویانی مجتبی کاویانی
مطالب
مروری بر Open Data Protocol و کاربردهای آن
مقدمه
OData قراردادی برای دسترسی به داده‌ها است که مایکروسافت آن را تحت مجوز Microsoft Open Specification Promise منتشر کرده است. این قرارداد استاندارد CRUD ایی را برای دسترسی به منبع داده از طریق وب سایت طراحی نموده است که از JDBC و ODBC ساده‌تر بوده و محدودیت ارتباط فقط با پایگاه داده‌های SQL ایی را ندارد.
OData از روی Atom Publishing Protocol و JSON ساخته شده و از مدل REST برای همه در خواست‌های خود استفاده می‌نماید. OData در واقع یک راه مشترک برای هر نوع کلاینت برای دسترسی به هر نوع داده ای است.

OData چهار قسمت اصلی دارد:

  1. OData data model که یک راه عمومی برای مدیریت و توصیف داده‌ها را فراهم می‌نماید
  2. OData protocol که به کلاینت اجازه ایجاد درخواست و پاسخ از سرویس دهنده OData را می‌دهد.
  3. OData client libraries که امکان ساخت ساده‌تر نرم افزار‌ها برای دسترسی به داده‌ها با قرارداد OData را می‌دهد.
  4. OData service سرویس دهنده و امکان دسترسی به داده‌ها را فراهم می‌سازد.
از مزیت‌های OData  می توان به موارد زیر اشاره نمود:
  1. ساده و انعطاف پذیر
  2. سورس باز بودن 
  3. امکان استفاده در سیستم‌های با داده‌های رابطه ای و غیر رابطه ای
  4. امکان استفاده از داده‌ها با منابع ای که آدرس پذیر هستند یعنی  دسترسی از طریق Url
  5. امکان دسترسی هر نوع گیرنده ای به داده ها
  6. امکان نمایش خروجی با فرمت Json  یا Xml 
  7. ...
کتابخانه‌های کار بار OData:
کتابخانه‌های بسیاری برای odata نوشته شده است که امکان استفاده آن را در اکثر زبان‌ها مهیا می‌سازد. 

اما بهترین کتابخانه WCF Data Services است که از سوی مایکروسافت ارائه شده و در اکثر تکنولوژی‌ها و محصولات خود قابلیت استفاده را دارد. WCF Data Services با پیاده سازی قرارداد OData ، توسعه دهندگان را از سطح پایین این قرارداد رهایی ساخته و به راحتی می‌توانند از ساختار شی گرا برنامه خود، در سرویس دهی با OData استفاده نمایند.

کاربرد‌های OData:
OData یک قرارداد سرویس دهی بر روی وب است که به هر نوع گیرنده که امکان دسترسی به وب را داشته باشد، امکان سرویس دهی دارد. به همین خاطر در اکثر برنامه‌های تحت وب یا نرم افرار‌های موبایل که می‌خواهیم اطلاعاتی را مابین سرویس دهنده و گیرنده ردوبدل کنیم حتی زمانیکه platform‌های مختلفی در کار باشند OData بهترین گزینه است. 
در مطالب بعدی با پیاده سازی مثال‌های با استفاده از WCF Data Services بیشتر با OData آشنا خواهید شد. در این اینجا هدف آشنایی اولیه با Odata و کاربردهای آن بود که امیدوارم مفید واقع شده باشد.
‫۱۱ سال و ۱۰ ماه قبل، یکشنبه ۳ دی ۱۳۹۱، ساعت ۱۹:۴۵
وحید نصیری وحید نصیری
مطالب
رهنمودهای کد نویسی سی شارپ 3

دو فایل زیر مقاله و خلاصه مقاله‌ای در مورد روش‌های بهتر کد نویسی با سی شارپ 3 هستند.


این رهنمودها (و نه استانداردها) جهت بالا بردن کیفیت کد‌های تهیه شده، یک دست شدن آن‌ها در یک سازمان، تهیه مستندات بهتر و امکان نگهداری ساده‌تر آن‌ها، بسیار مؤثرند.
تعدادی از آن‌ها را در مقاله‌ی "زیباتر کد بنویسیم" دیده‌اید. مقالات فوق گردآوری و به روز رسانی اینگونه نکات جهت پوشش دادن سی شارپ 3 می‌باشند.

ماخذ


‫۱۵ سال و ۲ ماه قبل، شنبه ۱۱ مهر ۱۳۸۸، ساعت ۲۱:۲۰
وحید نصیری وحید نصیری
نظرات مطالب
استفاده از Web API در ASP.NET Web Forms
- بله. گروه Web API و EF را در سایت پیگیری کنید.
- Web API یک بحث سمت سرور است. به آن به زبان ساده به چشم یک وب سرویس مدرن نگاه کنید. برای نمونه بجای وب‌متدهای استاتیک صفحات aspx یا فایل‌های ashx یا asmx و حتی سرویس‌های WCF از نوع REST و امثال آن، بهتر است از Web API استفاده کنید.  
- برای نمونه پایه مباحثی مانند Forms Authentication در اینجا هم کاربرد دارد (البته این یک نمونه است).
- برای کار با Web API الزاما نیازی به ASP.NET ندارید (نه وب فرم‌ها و نه MVC)؛ به هیچکدام از نگارش‌های آن. سمت کاربر آن AngularJS و سمت سرور آن Web API باشد. کار می‌کند. (اهمیت این مساله در اینجا است که الان می‌شود یک فریم ورک جدید توسعه‌ی برنامه‌های وب را کاملا مستقل از وب فرم‌ها و MVC طراحی کرد)
‫۱۰ سال و ۶ ماه قبل، دوشنبه ۱۵ اردیبهشت ۱۳۹۳، ساعت ۲۱:۵۵
وحید نصیری وحید نصیری
مطالب
آشنایی با فرمت OPML

OPML یا Outline Processor Markup Language اساسا فایلی است مبتنی بر XML که امروزه بیشتر جهت توزیع لینک‌های تغذیه خبری سایت‌ها (RSS/Atom و امثال آن) مورد استفاده قرار می‌گیرد.
به بیانی ساده‌تر، بجای این‌که بگویند ما به این 100 وبلاگ علاقمند هستیم و لینک تک تک آنها را به شما ارائه بدهند، یک فایل OPML استاندارد از آن‌ها درست کرده و در اختیار شما قرار می‌دهند. به این صورت با چند کلیک ساده، این فایل در نرم افزار فیدخوان شما import شده و آدرس‌ها بلافاصله قابل استفاده خواهند بود.
نمونه‌ای از این فرمت:
<?xml version="1.0" encoding="UTF-8"?>
<opml version="1.0">
  <head>
      <title>Subscriptions in Google Reader</title>
  </head>
  <body>
      <outline title="Programming">
          <outline
               text="Vahid's Blog"
               title="Vahid's Blog"
               type="atom"
               xmlUrl="http://feeds.feedburner.com/vahidnasiri"
               htmlUrl="https://www.dntips.ir/"/>
چند نمونه فایل OPML مرتبط با برنامه نویسی را از سایت‌های مختلف جمع آوری کرده‌ام که آنها را از این آدرس می‌توانید دریافت کنید.

نحوه استفاده از آنها در Google reader
بعد از ورود به قسمت تنظیمات Google reader ، با استفاده از قسمت import/export می‌توان یک فایل OPML را به آن معرفی کرد (شکل زیر):



و یا با استفاده از برنامه باکیفیت و رایگان FeedDemon و قسمت import feeds آن می‌توان یک فایل OPML را به برنامه وارد کرد. البته این‌جا امکانات بیشتری را نسبت به Google reader دراختیار شما قرار می‌دهد و می‌توانید از لیست دریافتی، موارد مورد نظر را انتخاب کنید و نه تمامی آنها را.




اگر علاقمند بودید که این فایل‌ها را در برنامه‌های دات نت خود import کنید، کتابخانه سورس باز Argotic Syndication Framework این امکان را در اختیار شما قرار می‌دهد.

به روز رسانی
- «از کدام فیدخوان تحت وب استفاده می‌کنید؟»  
- «به روز رسانی فایل OPML وبلاگ‌های IT ایرانی؛ شهریور 94»  
‫۱۵ سال و ۱۱ ماه قبل، چهارشنبه ۲۷ آذر ۱۳۸۷، ساعت ۰۲:۴۹
وحید نصیری وحید نصیری
مطالب
وضعیت فناوری‌های مرتبط با دات نت از دیدگاه مرگ و زندگی!

مطلبی که در ذیل آورده شده صرفا یک برداشت شخصی است بر اساس نقل قول‌ها و بررسی وضعیت اعضای تیم‌های مرتبط با فناوری‌های مختلف بکار گرفته شده در دات نت فریم ورک و ... نه رسمی!

ADO.NET ، DataSet ، DataTable و امثال آن: مرده! (مرده به معنای اینکه دیگر توسعه‌ی جدی نخواهد یافت)
ADO.NET‌ اولین فناوری دسترسی به داده‌ها در دات نت فریم ورک بود/است. مدل طراحی آن هم بر اساس امکانات زبان‌های آن زمان (زمان شروع به کار دات نت) بود (و تا دات نت 4 هم تغییر عمده‌ای نکرده). برای مثال در زمان ارائه اولین نگارش آن خبری از Generics نبود (در دات نت 2 اضافه شد)؛ یا LINQ وجود نداشت (در دات نت سه و سه و نیم اضافه و تکمیل شد). به همین جهت طراحی آن در حال حاضر (با وجود دات نت 4) بوی ماندگی می‌دهد (مانند استفاده از دیتاست و دیتاتیبل) و با ORM های مایکروسافت جهت استفاده از امکانات Generics و LINQ جایگزین شده‌ است.
البته این مورد تنها مورد مرده‌ای است که "باید" یاد گرفت؛ مهم نیست که ORMs ارائه شده‌اند. مهم این است که زیر ساخت تمام ORM های نوشته شده برای دات نت همین ADO.NET خام است.


LINQ to SQL : مرده!
مایکروسافت با این فناوری ORM های خودش را شروع کرد اما بعد از مدتی دید که بهتر است یک نسخه‌ی عمومی‌تر با پشتیبانی از بانک‌های اطلاعاتی دیگر مانند اوراکل، MySQL و غیره را نیز ارائه دهد. همینجا بود که آن‌را خیلی ساده با Entity framework جایگزین کرد و در roadmap ارائه شده صراحتا EF به عنوان راه حل توصیه شده دسترسی به داده‌های مایکروسافت اعلام شده است (+). حالا این وسط دیگر مهم نیست شما پروژه نوشته بودید یا هر چی. دیگر منتظر تغییرات خاصی در LINQ to SQL نباشید. فقط یک سری رفع باگ و نگهداری پروژه را شاهد خواهید بود. البته در همان زمان خیلی زود تکذیب کردند که LINQ to SQL مرده اما برای نمونه آقای Damien که عضو اصلی تیم LINQ to SQL بودند، اکنون در تیم XBOX مشغول به کار هستند! (+) تو خود شرح مفصل بخوان از این مجمل!

ضمنا این رو هم در نظر داشته باشید که LINQ != LINQ to SQL ؛ به عبارتی LINQ به خودی خود فقط یک language feature است.


Windows Forms یا به اختصار WinForms : مرده!
به نظر مظلوم‌تر از این یکی در دات نت یافت نمی‌شود! همین چند وقت پیش یکی از اعضای مایکروسافت این نظر سنجی رو برگزار کرده بود که "ما چکار کنیم که شما راحت‌تر از WinForms به WPF مهاجرت کنید؟!" (+)
در قاموس WPF ، ویندوز فرمز یعنی Canvas panel ؛ به عبارتی صلب‌ترین حالت طراحی رابط کاربری و این انتقال و مهاجرت هرچند برای کسانی که عمری را روی آن گذاشته‌اند، دردناک خواهد بود اما با وجود توانایی‌های WPF چیزی را از دست نخواهند داد. سیستم Layout (طرح بندی) در WinForms و همچنین دلفی، بر اساس قراردهی اشیاء در مختصات مطلقی در صفحه است. مثلا این دکمه‌ی خاص در آن نقطه‌ی معلوم قرار می‌گیرد و همین. این روش طرح بندی یکی از چندین روش طرح بندی در WPF است که اصطلاحا Canvas نام دارد. توصیه اکید و مطلق در WPF آن است که از Canvas فقط برای طراحی اشیاء گرافیکی پیچیده استفاده کنید و نه طراحی رابط کاربر. چرا؟ چون برای مثال در Silverlight که برادر کوچکتر WPF محسوب می‌شود، رابط کاربری آن باید بتواند همانند HTML انعطاف پذیر باشد و با اندازه‌های مختلف مرورگر یا اندازه‌ی قلم‌های بزرگتر هماهنگ شده و مقاومت کند، بدون اینکه از ریخت بیفتد و این مورد را سایر سیستم‌های طرح بندی رابط کاربر (منهای Canvas یا همان سیستم طرح بندی WinForms) ارائه می‌دهند. مورد دیگری که در WPF و Silverlight بسیار حائز اهمیت است ، Content Controls می‌باشد. چقدر خوب می‌شد بتوان داخل یک کنترل، کلا یک سیستم طرح بندی را تعریف کرد و اشیاء دلخواهی را داخل آن قرار داد. مثلا ToolTip پیش فرض وجود دارد. بسیار هم خوب. بنده علاقه دارم، متن عنوان آن ضخیم باشد. کنار آن یک تصویر کوچک و در سمت چپ آن متن قرار گیرد. برای انجام اینکار در WPF لازم نیست تا شما منتظر نگارش بعدی دات نت باشید که دست اندرکاران مربوطه با افتخار در یک سند 50 صفحه‌ای توضیح دهند که چگونه می‌توان اینکار را انجام داد. یک سیستم طرح بندی را اضافه کنید. موارد ذکر شده را در آن تعریف کنید. بدون استفاده از هیچ نوع کامپوننتی یا بدون منتظر ماندن تا نگارش بعدی این محصولات، به مقصود خود رسیده‌اید.


ASP.NET Web forms : داره نفس‌های آخرش رو می‌کشه!
از زمانیکه ASP.NET MVC آمد نسخه‌ی Web forms تقریبا فراموش شد. به وبلاگ اسکات گاتری یا Haacked و سایر اعضای اصلی دات نت که مراجعه کنید در سه سال اخیر در حد تعداد انگشتان یک دست هم در مورد Web forms مطلب ننوشته‌اند. تمام تمرکز و نوآوری‌ها بر روی MVC متمرکز شده و حتی در نسخه‌ی 4 دات نت هم فقط یک سری صافکاری مختصر را در Web forms شاهد بودیم مثلا نام کنترل‌ها را خودتان هم در زمان رندر نهایی می‌توانید تعیین کنید! یا لطفا کردند و قسمتی از url routing موجود در ASP.NET MVC را به ASP.NET web forms 4 هم قرض دادند (این مورد شاید مهم‌ترین تغییر قابل ذکر در ASP.Net web forms 4 است).
البته این رو هم اضافه کنم که ASP.NET MVC‌ واقعا قابل احترام است؛ هدف از آن جدا سازی لایه‌های برنامه با الگوهای استاندارد صنعتی (و نه هر روش برنامه نویسی چند لایه من درآوردی)، ترویج کد نویسی بهتر، ترویج Unit testing ، رفع یک سری مشکلات ASP.NET Web forms (مثلا از ViewState های حجیم دیگر خبری نیست) و امثال آن است.
برای نمونه توجه شما را به مطلبی که آقای Dino Sposito در مورد ASP.NET Webforms نوشته جلب می‌کنم: (+)
به صورت خلاصه ایشان عنوان کرده زمان طراحی ASP.NET Webforms در 10 سال قبل، هدف ما انتقال ساده‌تر برنامه نویس‌های VB به محیط وب بود. به همین جهت دست به اختراع postback ، viewState ، کنترل‌های سمت سرور و غیره زدیم. (بنابراین تاکید تمام این‌ها این است که webforms فناوری دهه قبل "بود" و الان بنابر نیازهای جدید دست به طراحی مجدد زده‌ایم)

در مورد "پایان پروژه ASP.NET Ajax Control Toolkit" هم قبلا مطلب نوشته بودم و این یکی واقعا official است!


و در پایان باید متذکر شد که فلان فناوری مرده یا داره نفس‌های آخرش رو می‌کشه اصلا مهم نیست. هنوز هم هستند سازمان‌هایی که برنامه‌های نوشته شده با ASP کلاسیک (نگارش قبل از ASP.NET Web forms) خود را دارند و خیلی هم از آن راضی هستند!
این موارد رو از این جهت نوشتم که اگر می‌خواهید تازه به این جمع وارد شوید دقیقا بدانید باید روی چه مواردی بیشتر وقت بگذارید و یادگیری کدامیک صرفا اتلاف وقت خواهند بود (مثلا EF بر LINQ to SQL ارجح است و اگر امروز می‌خواهید شروع کنید با EF شروع کنید، یا دیگر کم کم با وجود WPF ، بازار کاری برای WinForms نخواهد بود).

‫۱۳ سال و ۱۰ ماه قبل، چهارشنبه ۱۵ دی ۱۳۸۹، ساعت ۰۲:۱۸
برات جوادی برات جوادی
مطالب
MongoDB #4
مدل کردن داده در MongoDB
داده در MongoDB شمای منعطفی دارد. سندها در یک مجموعه به تعدادی از فیلدها با ساختاری شبیه به هم نیازی ندارند و فیلدهای مشترک در یک سند مجموعه ممکن است نوع‌های داده‌ی متفاوتی را نگهداری کنند.
برخی ملاحظات هنگام طراحی شمای در MongoDB
  • شمای خود را بر اساس نیازمندی‌های کاربر طراحی کنید.
  • آبجکت هایی را که از آنها باهم استفاده می‌کنید، داخل یک سند ترکیب کنید؛ درغیر اینصورت آنها را جدا کنید (اما مطمئن شوید که نباید نیازی به استفاده از Join باشد).
  • داده را بصورت محدود تکثیر کنید؛ چون فضای دیسک ارزانتر است از محاسبه زمان.
  • عمل Join را هنگام ذخیره کردن انجام دهید، نه موقع خواندن.
  • شمای خود را برای بیشترین موارد استفاده بهینه کنید.
  • تجمع‌های پیچیده (Complex Aggregation) را در شمای انجام دهید.

مثال
فرض کنید یک کاربر نیاز به طراحی یک پایگاه داده برای وب سایت خود دارد. تفاوت‌های طراحی شمای بین RDBMS و MongoDB را در ادامه ملاحظه خواهید کرد. وب سایت نیازمندهای زیر را دارد:
  • هر پست یک عنوان یکتا، توضیحات و آدرس اینترنتی دارد.
  • هر پست می‌تواند یک یا چند برچسب داشته باشد.
  • هر پست نام نویسنده و تعداد Like‌ها را دارد.
  • هر پست تعدادی نظر معین را توسط کاربران همراه با نامشان، پیام، تاریخ ثبت و تعداد Likeها، دارد.
  • در هر پست صفر یا چند نظر وجود دارد.
در طراحی شمای توسط RDMBS برای نیازمندی‌های فوق، حداقل سه جدول نیاز است. 

درحالیکه در طراحی شمای توسط MongoDB یک مجموعه از پست را با ساختار زیر خواهیم داشت:
{
   _id: POST_ID
   title: TITLE_OF_POST, 
   description: POST_DESCRIPTION,
   by: POST_BY,
   url: URL_OF_POST,
   tags: [TAG1, TAG2, TAG3],
   likes: TOTAL_LIKES, 
   comments: [
      {
         user:'COMMENT_BY',
         message: TEXT,
         dateCreated: DATE_TIME,
         like: LIKES 
      },
      {
         user:'COMMENT_BY',
         message: TEXT,
         dateCreated: DATE_TIME,
         like: LIKES
      }
   ]
}
بنابراین هنگام نمایش داده در RDBMS نیاز به تهیه Join بین سه جدول دارید؛ اما در MongoDB داده‌ها از یک مجموعه نمایش داده خواهند شد. 
‫۹ سال و ۹ ماه قبل، چهارشنبه ۱ بهمن ۱۳۹۳، ساعت ۱۳:۲۵