وحید نصیری وحید نصیری
نظرات مطالب
ASP.NET MVC #1
سلام، سال نوی شما هم مبارک.
- این کار مستقل است و مرتبط به فیلم خاصی نیست.
‫۱۲ سال و ۸ ماه قبل، پنجشنبه ۳ فروردین ۱۳۹۱، ساعت ۱۹:۰۶
مهمان مهمان
نظرات مطالب
دریافت فایل از یوتیوب
سلام

مطلب بسیار جالب و مفیدی بود.
امیدوارم سال بسیار خوب و پر برکتی (پر از سفارش کار)داشته باشید.

موفق و پیروز باشید
‫۱۴ سال و ۸ ماه قبل، جمعه ۶ فروردین ۱۳۸۹، ساعت ۱۳:۵۷
مهمان مهمان
بازخوردهای پروژه‌ها
بهبود امنیتی کلمات عبور

سلام؛ در کلاس encryptor کلمات عبور اصطلاحا hard coded هستند و این یک نقص امنیتی به شمار می‌رود؛ چون شخص حمله کننده می‌تواند بر این اساس، اطلاعات را رمزگشایی کند. بهتر است آن‌ها را به فایل web.config برنامه منتقل کرد و از آنجا خواند.

‫۱۱ سال و ۱۲ ماه قبل، چهارشنبه ۱ آذر ۱۳۹۱، ساعت ۱۵:۰۵
مهمان مهمان
نظرات مطالب
خلاصه اشتراک‌های روز سه شنبه 17 آبان 1390
سلام مهندس
نمیشه خلاصه اشتراک‌ها یک ساعت زودتر ارسال بشه که ما یک ساعت زودتر بخوابیم!!!
‫۱۲ سال و ۱۲ ماه قبل، چهارشنبه ۱۸ آبان ۱۳۹۰، ساعت ۰۳:۴۵
فرید بکران فرید بکران
مطالب
بازسازی کد: استخراج کلاس (Extract class)
زمانیکه کلاسی، دو یا چند کار را انجام می‌دهد، بهتر است این امور در کلاس‌های مجزایی انجام شوند. راه اصلی این کار، بازسازی کد استخراج کلاس است. ایده اصلی این بازسازی کد با ساختن کلاسی جدید و انتقال خصوصیت‌ها، فیلدها و متدهای مورد نظر به آن انجام می‌شود.
کلاس‌ها معمولا از ابتدا به صورت چند وظیفه‌ای و پیچیده طراحی و پیاده سازی نمی‌شوند. اما با گذشت زمان معمولا کلاس‌ها پیچیده‌تر می‌شوند. این پیچیدگی تاثیر مستقیمی را بر روی قابلیت نگهداری نرم افزار خواهد داشت. 
تشخیص کلاسی که نیاز به جداسازی دارد امر مهمی است. روش‌های مختلفی نیز برای این کار وجود دارد که در زیر اشاره شده‌است. با دیدن نشانه‌هایی مانند نشانه‌های زیر می‌توانید اطمینان داشته باشید که کلاس مورد نظر شما نیاز به جداسازی دارد.
  • تعدادی خصوصیت و فیلد و متد در کلاس وجود دارند که به نظر می‌رسد فقط باهم کار می‌کنند.
  • زیر مجموعه‌ای از داده‌های کلاس، معمولا همراه هم تغییر می‌کنند یا به یکدیگر وابسته هستند.
  • با تغییر بدنه متدی، نیاز شود متدهای دیگری در همان راستا تغییر کنند.
  • ارث بری‌ها تنها به صورت دسته‌ای بر اعضای کلاس اثر می‌گذارند.  

مراحل انجام این بازسازی کد  

  1. تصمیم بگیرید که به چه صورت کلاسی را تقسیم خواهید کرد.
  2. کلاس جدیدی بسازید که نشان دهنده مسئولیت‌های جدید تقسیم شده باشد. اگر نام کلاس قدیمی با مسئولیت‌های باقی مانده برای آن همخوانی نداشت، نام آن را تغییر دهید 
  3. فیلدها و خصوصیات کلاس قدیمی را با استفاده از بازسازی Move field به کلاس جدید منتقل نمایید.
  4. کد را برای هر انتقال کامپایل و تست نمایید.
  5. متدهای کلاس قدیمی را با استفاده از بازسازی جابجایی متد به کلاس جدید منتقل نمایید.
  6. کد را برای هر انتقال، کامپایل و تست نمایید.
مثال   (برای سادگی توضیح، موضوع مثال‌ها بسیار ساده در نظر گرفته شده‌اند)
فرض کنید بخشی از نرم افزار تولید شده، مسئولیت مدیریت صورت حساب‌ها و پرداخت‌ها را بر عهده دارد. در این زیر سیستم کلاس مدیریت کننده صورت حساب‌ها و پرداخت‌ها به اسم InvoiceService ساخته شده‌است. بدنه این کلاس به صورت زیر است:   
public class InvoiceService 
{ 
    public void AddInvoice() 
    { 
    } 
    public void DeleteInvoice() 
    { 
    } 
    public void AddOfflinePayment(int invoiceId) 
    { 
    } 
    public void AddOnlinePayment(int invoiceId) 
    { 
    } 
}
متدهای AddOfflinePayment و AddOnlinePayment مسئولیت ذخیره یک پرداخت را برای صورت حساب مشخص شده، دارند. 
متدهای دیگری نیز برای ذخیره و حذف صورت حساب‌ها در این کلاس مشاهده می‌شود. 
اگر کلاس InvoiceService با این تعداد عضو باقی بماند احتمالا مشکل خاصی پیش نخواهد آمد. مشکل زمانی بوجود می‌آید که تعداد اعضای بیشتری برای مدیریت پرداخت‌ها و صورت حساب‌ها نیاز باشد. طراحی فعلی این کلاس موارد مربوط به پرداخت و صورت حساب را تلفیق کرده‌است. طراحی بهتر این کلاس، بازسازی استخراج کلاس است. به این صورت که کلاسی مجزا برای مدیریت امور پرداخت ایجاد شود. به این ترتیب کلاس‌هایی با مسئولیت‌های مشخص خواهیم داشت. تکه کد زیر تغییرات کلاس InvoiceService را نشان می‌دهد:   
public class InvoiceService 
{ 
    public void AddInvoice() 
    { 
    } 
    public void DeleteInvoice() 
    { 
    } 
} 
public class PaymentService 
{ 
    public void AddOfflinePayment(int invoiceId) 
    { 
    } 
    public void AddOnlinePayment(int invoiceId) 
    { 
    } 
}
تغییرات اعمال شده ساده هستند، اما با در نظر گرفتن تاثیر مثبت فراوان کلاسهای تک وظیفه‌ای، این تغییر می‌تواند اثر بسیار خوبی بر روی قابلیت نگهداری نرم افزار نیز داشته باشد. 
نمونه‌های دیگری از بازسازی کد استخراج متد که بیشتر مشاهده کرده‌ام، به صورت زیر هستند:  
  • تقسیم کلاس‌های controller بر اساس قوانین طراحی REST 
  • تقسیم کلاس‌های داده (data model) بر اساس قوانین شیءگرایی و تک وظیفگی  
نظر شما چیست؟ بیشترین موارد نیاز به استخراج کلاس را در چه بخش‌هایی از کد مشاهده کرده‌اید؟
‫۶ سال و ۹ ماه قبل، یکشنبه ۱ بهمن ۱۳۹۶، ساعت ۱۳:۲۰
مهران بادامی مهران بادامی
نظرات مطالب
سفارشی سازی Binding یک خصوصیت از طریق Attributes
سلام 
من یهBinding نوشتم برای تاریخ که شمسی از کاربر گرفته به میلادی میدهد برای دخیره تو DB ولی وقتی میخواهم تاریخ که تو دیتابیسم میلادی هست را نشان بدهم همون میلادی نشون میده برای نمایش به شمسی چه کنم؟ 
‫۱۰ سال و ۱۱ ماه قبل، یکشنبه ۲۶ آبان ۱۳۹۲، ساعت ۲۳:۵۴
بهمن خلفی بهمن خلفی
نظرات نظرسنجی‌ها
در محیط برنامه نویسی از دارک مود استفاده می کنید یا لایت مود؟
درود به همه دوستان و با احترام به همه نظرات
بنده تقریبا از زمانی که dark mode در دسترس قرار گرفت از این حالت تیره استفاده میکنم ، خوب قبلا از محیط روشن light mode استفاده میکردم تجربیاتی که داشتم رو ذکر میکنم :
  1. به دلیل کار بیش از 10 ساعت روزانه ، با توجه به اینکه مشکل بینایی نداشتم ولی حالت روشن باعث عصبی بودن و بیخوابی مزمن شده بود با تغییر محیط به حالت تیره تاثیر بسیار زیادی در کیفیت خواب داشتم بصورتی که این موضوع کاملا محسوس بود.
  2. از طرفی کار با 2 یا 3 مانیتور با حالت روشن ، نیاز به دقت بیشتری دارد و خستگی زیادی رو به چشم تحمیل میکند و مدت زمان کمتری با دقت بالا میتونستم کار کنم و تمرکزم به دلیل صفحه سفید کمتر بود.
  3. اگر محیط نور مناسب و ملایمی داشته باشد و از پشت سر باشد حالت روشن خستگی کمتری خواهد داشت و چشم رو کمتر اذیت میکنه ولی در حالت تیره خستگی چشم خیلی کمتر خواهد بود و تداخل رنگی کمتری داریم.
  4. برای برنامه نویسی بلند مدت ، حالت تیره و برای طراحی گرافیک و کار با تصاویر حالت روشن (به دلیل وضوح مناسب ) بیشتر توصیه میکنم .
مشاغل مشابه برنامه نویسی و کار با کامپیوتر به دلیل عدم تحرک کافی بدن و پشت میز نشینی آسیبهای زیادی را وارد میکند اما در هر صورت به نظرم هر کسی قبل از انتخاب محیط کاری خود باید با یک چشم پزشک آشنا به تکنولوژی و شغل مورد نظر ، مشاوره کند تا بتواند از محیط شغلی خودش کمتر آسیب ببیند.

‫۱ سال و ۵ ماه قبل، دوشنبه ۱۴ فروردین ۱۴۰۲، ساعت ۰۴:۴۹
وحید نصیری وحید نصیری
مطالب
در مورد ادامه ...

در حال تهیه یک سیستم blogging هستم که بشود آن‌را چند کاربره یا چند نویسنده‌ای کرد. این سیستم جدید تا یک ماه دیگر جایگزین سیستم وصله پینه‌ای جاری خواهد شد (متن یکجا، css لینک شده از یک سایت دیگر، syntax highlighting از یک سایت دیگر، عکس‌ها در یک سرور مجزا، کامنت‌ها کلا در یک سرور دیگر (دیسکاس) بجز هاست بلاگر، لینک‌های روزانه در یک سایت ثالث، فایل‌های مثال‌ها در سروری دیگر! هاست اصلی بلاگ (بلاگر) هم کلا در ایران فیلتر است!). البته همین سیستم وصله پینه‌ای 4 سال است که داره کار می‌کنه!
به همین دلیل برای پیدا کردن وقت جهت بازنویسی سیستم، این سایت تا یک ماه دیگر در حالت تعلیق خواهد بود.
در این بین اگر علاقمند به مشارکت در بلاگ جدید (با همین آدرس با همین عنوان) به عنوان نویسنده هستید، یک ایمیل به من ارسال کنید (vahid_nasiri در یاهو). موضوع سایت مشخص است. اهداف آن هم به همین ترتیب. فقط فنی است. تنها مطالب فنی قرار است ارسال شود. پس از آماده شدن سایت جدید، یک اکانت نویسنده مطلب برای شما ارسال خواهد شد. با تشکر از همکاری شما.

‫۱۲ سال و ۶ ماه قبل، چهارشنبه ۳ خرداد ۱۳۹۱، ساعت ۱۶:۳۸
وحید نصیری وحید نصیری
نظرات مطالب
بهبود SEO در ASP.NET MVC
ممنوع کردن ورود session id در آدرس

سایت‌های ASP.NET به یک چنین آدرس‌هایی پاسخ مثبت می‌دهند:
http://yourserver/folder/(session ID here)/
داخل پرانتز session id ذکر شده‌است و برای حالت cookie less است. حتی اگر استفاده‌ی از کوکی را اجباری کرده باشید، باز هم می‌توان آدرس فوق را درخواست داد و کار می‌کند (البته بدون تاثیر امنیتی است و پردازش نمی‌شود) ولی می‌تواند سبب بروز مشکل «وجود آدرس‌هایی با محتوای تکراری» در سایت شود.
برای ممنوع کردن یک چنین آدرس‌هایی می‌توان تنظیم ذیل را اضافه کرد:
    <rewrite>
      <rules>
        <rule name="Remove Session ID From URL" patternSyntax="ECMAScript" stopProcessing="true">
          <match url=".*" />
          <conditions>
               <add input="{CACHE_URL}" pattern="^(.+):\/\/(.+)\/\((.*)\)\/(.+)" />            
          </conditions>
          <action type="Redirect" url="https://www.dntips.ir/" redirectType="Permanent" />
        </rule>
      </rules>
    </rewrite>
‫۸ سال و ۵ ماه قبل، چهارشنبه ۲۹ اردیبهشت ۱۳۹۵، ساعت ۱۸:۲۵
وحید نصیری وحید نصیری
نظرات مطالب
Repository ها روی UnitOfWork ایده خوبی نیستند
- How EF6 Enables Mocking DbSets more easily
- Testing with a mocking framework - EF6 onwards 

+ شخصا اعتقادی به Unit tests درون حافظه‌ای، در مورد لایه دسترسی به داده‌ها ندارم. به قسمت «Limitations of EF in-memory test doubles» مراجعه کنید؛ توضیحات خوبی را ارائه داده‌است.
تست درون حافظه‌ی LINQ to Objects با تست واقعی LINQ to Entities که روی یک بانک اطلاعاتی واقعی اجرا می‌شود، الزاما نتایج یکسانی نخواهد داشت (به دلیل انواع قیود بانک اطلاعاتی، پشتیبانی از SQL خاص تولید شده تا بارگذاری اشیاء مرتبط و غیره) و نتایج مثبت آن به معنای درست کار کردن برنامه در دنیای واقعی نخواهد بود. در اینجا Integration tests بهتر جواب می‌دهند و نه Unit tests.
‫۱۰ سال و ۶ ماه قبل، سه‌شنبه ۹ اردیبهشت ۱۳۹۳، ساعت ۰۲:۱۰