10 نکته برای نوشتن بهتر توضیحات در سورس کد

نوشتن توضیحات یا Comment در تمام زبان های برنامه نویسی مرسوم است. برنامه نویس ها معمولاً برای خواناتر شدن کدهای خود توضیحات می نویسند، اما در برخی مواقع به طور خواسته یا ناخواسته این توضیحات به جای اینکه سودمند باشند آزاردهنده می شوند. در این مطلب نکاتی ذکر خواهد شد که با بکار بستن آن ها می توان توضیحاتی خوانا و قابل درک در برنامه ها نوشت.

1) توضیحات را مرتب و پشت سر هم بنویسید : هنگامی که برای چند خط کد به صورت متوالی کامنت می نویسید بهتر است تمام کامنت ها در یک ستون عمودی تراز شوند تا خواناتر به نظر برسند.

List<User> users = User.GetAll(); //Get all available users
users.Add(aUser);                 //Add a User

2) در کوتاه ترین جملات منظور خود را برسانید : سعی نکنید قضیه را بپیچانید! با کمترین کلمات ممکن منظور خود را برسانید و از نوشتن توضیحات اضافی پرهیز کنید.

3) بدانید برای چه چیزی توضیح می نویسید : نوشتن کامنت برای یک کلاس با نوشتن کامنت برای یک پراپرتی یا یک متد فرق می کند. برای یک کلاس شما باید یک خلاصه توضیحات، نام نویسنده و تاریخ آخرین تغییر را بنویسید و کاری را که این کلاس قرار است انجام بدهد را مشخص کنید. برای یک متد شما باید علاوه بر نوشتن یک توضیح خلاصه، توضیحی در مورد هر یک از پارامترهای متد و نوع خروجی متد بنویسید.

4) به شعور خواننده توهین نکنید! : از توضیح بدیهیات پرهیز کنید. نوشتن توضیحاتی شبیه به توضیحات زیر را کنار بگذارید :

if(CanSave == true) //if User can Save
SaveToFile();       //then Save it to file!

نوشتن این گونه توضیحات به جز اینکه وقت شما و خواننده کد را بگیرد، هیچ سود دیگری ندارد.

5) از یک استاندارد مشخص پیروی کنید : مخصوصاً وقتی با یک تیم برنامه می نویسید این مورد را حتماً رعایت کنید. کامنت کردن کدها بر اساس استاندارد و استفاده از ابزارهای مربوطه بسیار توصیه می شود. به طور مثال در C# استفاده از توضیحات XML مرسوم است و کار شما را آسان می کند.

6) توضیحات را همزمان با نوشتن کد بنویسید : زمانی که شروع به کد نویسی می کنید ذهن شما بر روی مسئله جاری متمرکز شده است و بهترین زمان برای نوشتن توضیحات در مورد کد مورد نظر است. اگر نوشتن توضیحات را به زمان دیگری موکول کنید ممکن است توضیحاتی که بعداً می نویسید همانی نباشد که در ابتدا در ذهن شما بوده است.

7) طوری توضیحات بنویسید که دوست دارید دیگران برای شما بنویسند! : موقعیتی را در نظر بگیرید که باید کدهای کلاسی که یک برنامه نویس دیگر نوشته است را تغییر دهید و کدهای نوشته شده هم آنقدر ناخواناست که بدون خواندن توضیحات نمی توانید از آن ها سر در بیاورید. اگر آن برنامه نویس توضیحات خوانایی برای این کدها ننوشته باشد کار شما برای تغییر کدها بسیار سخت خواهد بود. پس طوری کامنت بنویسید که برنامه نویس بخت برگشته ای که بعد از شما می خواهد کدها را تغییر دهد عذاب نکشد! با این کار اول خودمان سود خواهیم کرد، زیرا ممکن است اولین نفری باشیم که در آینده می خواهیم کدهای خودمان را تغییر دهیم.

8 ) با تغییر کدها، توضیحات را تغییر دهید : همیشه کامنت ها را به صورت موازی با کدهای خود تغییر دهید. اگر کدهای خود را تغییر دهید اما توضیحاتش را آپدیت نکنید، به جای اینکه این توضیحات در آینده سودمند باشند، نگهداری کد را سخت تر خواهند کرد. نداشتن توضیحات در سورس کد بهتر از داشتن توضیحات غلط در آن است. حواستان به ابزارهای Refactoring باشد که کدها را به صورت خودکار تغییر می دهند اما توضیحات را بدون تغییر رها می کنند.

9) از برچسب های معنی دار استفاده کنید : زمانی که در یک تیم کار می کنید، سعی کنید از برچسب های معنی دار و قراردادی بین اعضای تیم برای منظورهای مختلف استفاده کنید. به طور مثال بسیاری از برنامه نویس ها از برچسبی مثل «//TODO :» استفاده می کنند تا مشخص کنند قسمتی از کد نیاز به کار اضافی دارد و یا از برچسبی مثل «Temp» جهت نوشتن کدهای موقت که بعداً باید حذف یا جایگزین شوند استفاده می کنند. شاید برچسب ها توضیحی در مورد کد نباشند، اما به جای آن پیغامی را به شما و دیگر هم تیمی های شما یادآوری می کنند.

10) کد خوب، خودش را توضیح می دهد : همیشه بخاطر داشته باشید که کد خوب بهترین داکیومنت برای خودش است. اگر دوست ندارید یا حوصله ندارید برای کدهایتان کامنت بنویسید بهتر است کدهایی بنویسید که خودشان را توضیح می دهند. برای نوشتن چنین کدهایی باید نام متغیرها، کلاس ها، متدها و پراپرتی ها را کاملاً معنی دار انتخاب کنید. به طور مثال شما نیازی به نوشتن کامنت برای متد زیر ندارید :

AddUserToDatabase(User user)

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

 

منبع : 13 Tips to Comment Your Code

استفاده از jQuery UI Dialog در ASP.NET

یکی از نیازهای مهم برنامه نویسان وب، مخصوصاً هنگام توسعه وب اپلیکیشن ها، استفاده از دیالوگ ها برای کاربردهای مختلف است. در حالی که در برنامه های ویندوزی استفاده از پنجره های دیالوگ امری رایج و ساده است، در محیط وب اینگونه نیست. در واقع در وب چیزی که به عنوان دیالوگ در ویندوز می شناسیم وجود ندارد، و باید با همین صفحات معمولی و مقداری کد جاوا اسکریپت یک پنجره دیالوگ را ایجاد کنیم. این مسئله در برخی مواقع واقعاً مشکل ساز می شود و دست برنامه نویس را می بندد.

خوشبختانه کتابخانه jQuery UI دارای یک کامپوننت Dialog مناسب برای استفاده در محیط وب است که با تمامی مرورگرهای مدرن سازگاری کامل دارد و به علت اینکه بر روی کتابخانه jQuery کار می کند در تمام پلت فرم های توسعه وب قابل استفاده است.

برای استفاده از این Dialog در یک صفحه ASP.NET باید کتابخانه های jQuery و jQuery UI را دانلود کنید و در صفحه مورد نظر خود به آن ها ارجاع اسکریپتی بدهید. در این مطلب یک مثال ساده در مورد استفاده از jQuery UI Dialog  را توضیح خواهیم داد. پروژه مثال این مطلب را از اینجا دریافت کنید. قصد ندارم تمام کدهای نوشته شده در این پروژه مثال را توضیح بدهم، فقط نکات مهم مربوط به موضوع بحث را خواهید خواند. خواندن سورس کد و مشاهده مثال بهتر از توضیحات متنی به شما کمک می کند.

پس از دانلود و اجرای پروژه، با یک صفحه ساده مواجه خواهید شد که یک دکمه با عنوان Set Values در آن وجود دارد. با کلیک کردن بر روی این دکمه یک دیالوگ jQuery شبیه به تصویر زیر خواهید داشت :

jQuery UI Dialog Exampleدکمه Cancel دیالوگ را می بندد و دکمه OK برچسب های روی صفحه را با مقادیر تکست باکس ها هماهنگ می کند. jQuery UI Dialog در حالت معمول بعد از تگ form در ASP.NET رندر می شود که این باعث می شود تا دکمه های موجود در دیالوگ هیچ Post Backی به صفحه نداشته باشند که البته این مشکل به راحتی حل می شود. برای اینکه دکمه های موجود در دیالوگ بدون رفرش شدن صفحه کار خود را انجام بدهند، محتویات دیالوگ را درون یک UpdatePanel قرار می دهیم. مهمترین کدهایی که در مورد آن ها بحث می کنیم، کدهای جاوا اسکریپت زیر هستند :

<script type="text/javascript">
 $(document).ready(function () {
 $('#divValues').dialog({
 autoOpen: false,
 draggable: true,
 maxHeight: 440,
 width: 400,
 modal: true,
 title: "Enter values",
 open: function (type, data) {
 $(this).parent().appendTo("form");
 }
 });
 });

 function openDialog(id) {
 $('#' + id).dialog("open");
 }

 function closeDialog(id) {
 $('#' + id).dialog("close");
 }

 </script>

در واقع این کدهای بالا هستند که دیالوگ jQuery را می سازند و آن را باز و بسته می کنند. علامت $ که در ابتدای کد بکار رفته نشان دهنده این است که در حال استفاده از توابع کتابخانه jQuery هستیم. تابع اول دیالوگ را با خصوصیات مشخص شده مقدار دهی می کند. لیست کامل این خصوصیات را می توانید اینجا مشاهده کنید و بر اساس نیاز خود تغییر دهید. بعد از اجرای برنامه، تا زمانی که تابع openDialog صدا زده نشود، دیالوگ ما هم نشان داده نخواهد شد و در واقع jQuery آن را از دید کاربر مخفی نگه خواهد داشت. محتویات یک دیالوگ باید در یک div قرار بگیرند که نام آن باید برای dialog مشخص شود. نکته ای که شما به عنوان یک برنامه نویس ASP.NET در این مورد باید بدانید این است که حتماً UpdatePanel دیالوگ را داخل این div قرار دهید تا کدهایتان به درستی کار کند.

ویژگی خوب کتابخانه jQuery UI سبک بودن و سازگار بودن با اکثر مرورگرهای مدرن امروزی است. برای تغییر ظاهر دیالوگ هم دست شما بسیار باز است و می توانید از تم های آماده jQuery UI استفاده کنید و یا حتی استایل خود را برای آن بسازید.

دریافت پروژه مثال

ویژگی جدید Code-first برای Entity Framework

با محبوب شدن NHibernate و کتابخانه های وابسته به آن مثل Castle ActiveRecord و Fluent NHibernate، مایکروسافت به تازگی ویژگی جدیدی را به صورت Preview برای ORM خود یعنی Entity Framework عرضه کرده است که قابلیت هایی جدیدی را به توسعه دهندگان می دهد تا به جای سر و کله زدن با ابزارهای Designer و فایل های نگاشت XML، بر کدهای شیء گرا تمرکز داشته باشند. با این ویژگی شما به راحتی می توانید مدل خود را با استفاده از کلاس های معمولی بسازید و از EF بخواهید تا دیتابیس را از روی مدل نوشته شده توسط شما بسازد.

نسخه ای که به تازگی عرضه شده آخرین نسخه کتابخانه Code first قبل از ارائه نسخه اصلی خواهد بود. برای دانلود این ویژگی جدید به این صفحه از سایت مایکروسافت بروید. بعد از نصب کتابخانه، برای استفاده از این ویژگی پروژه جدیدی از نوع Class Library ایجاد کنید و به فایل EntityFramework.dll در مسیر نصب شده ارجاع دهید. یک کلاس به نام Blog با محتویات زیر بسازید :

using System.Collections.Generic;<br />
using System.ComponentModel.DataAnnotations;<br />
using System.Data.Entity;</p>
<p>namespace BlogModel<br />
{<br />
public class Blog<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Title is required.")]<br />
public string Title { get; set; }</p>
<p>public bool ShowInSearchEngines { get; set; }</p>
<p>public string Description { get; set; }</p>
<p>public IList<Post> Posts { get; set; }<br />
}<br />
}

می خواهیم مدلی بسازیم برای نگهداری اطلاعات یکسری وبلاگ به علاوه پست ها و کامنت های هر کدام. در اینجا شما می توانید کلاس هایی ایجاد کنید که هر کدام نشان دهنده یک موجودیت در دیتابیس شما خواهند بود. این کلاس ها می توانند کلاس های ساده POCO باشند که نیازی ندارند از کلاس دیگری به ارث بروند تا نقش یک Entity را برای شما بازی کنند. این ویژگی به شما کمک می کند تا یک مدل ساده، قابل درک، تمیز و قابل تست برای پروژه خود بسازید. کلاس های مثال ما همگی POCO هستند.

using System.Collections.Generic;<br />
using System.Data.Entity;<br />
using System.ComponentModel.DataAnnotations;</p>
<p>namespace BlogModel<br />
{<br />
public class Post<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Title is required.")]<br />
public string Title { get; set; }</p>
<p>[StringLength(4000)]<br />
[Required(ErrorMessage="Content is required.")]<br />
public string Content { get; set; }</p>
<p>public Blog Blog { get; set; }</p>
<p>public IList<Comment> Comments { get; set; }<br />
}<br />
}

کلاس Post برای نگهداری اطلاعات یک پست وبلاگ نوشته شده است. Post با موجودیت Blog یک رابطه چند به یک و با موجودیت Comment یک رابطه یک به چند دارد که با استفاده از پراپرتی در آن مشخص شده اند. با استفاده از قابلیت های فضای نام DataAnnotations می توان مشخصات یک موجودیت را اعتبار سنجی نمود. این اعتبار سنجی با استفاده از تعریف Attribute بر روی مشخصات انجام می شود. به طور مثال پراپرتی Content در این موجودیت می تواند تا 4000 کاراکتر را در خود ذخیره کند و حتماً باید مقداری برای آن وارد شود وگرنه یک استثنا رخ خواهد داد که باید توسط برنامه نویس هندل شود.

using System.Data.Entity;<br />
using System.ComponentModel.DataAnnotations;</p>
<p>namespace BlogModel<br />
{<br />
public class Comment<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Name is required.")]<br />
public string Name { get; set; }</p>
<p>[Required(ErrorMessage="Email is required.")]<br />
public string Email { get; set; }</p>
<p>public string URL { get; set; }</p>
<p>[Required]<br />
public string Content { get; set; }</p>
<p>public Post Post { get; set; }<br />
}<br />
}<br />

استفاده از مشخصه های اعتبارسنجی باعث می شود که مدل ما به صورت خودکار در هنگام ذخیره در دیتابیس، اطلاعات خودش را مورد بررسی قرار دهد تا در صورت وجود یک داده نا معتبر از ذخیره شدن اطلاعات درون دیتابیس جلوگیری کند. برای اتمام مدل خودمان در این مثال فقط یک قدم دیگر مانده و آن هم ایجاد یک کلاس DbContext برای کلاس های ساده مان است :

using System.Data.Entity;</p>
<p>namespace BlogModel<br />
{<br />
public class MyBlogPlatform: DbContext<br />
{<br />
public DbSet<Blog> Blogs { get; set; }<br />
public DbSet<Post> Posts { get; set; }<br />
public DbSet<Comment> Comments { get; set; }<br />
}<br />
}<br />

در واقع این کلاس باعث می شود تا کلاس های ساده ی ما با دیتابیس بوسیله Map کردن کلاس ها به جدوال و پراپرتی ها به فیلدها و رابطه ها  ارتباط برقرار کنند. کدهای بالا تمام کدهای لازمی بود که ما برای ایجاد مدل و لایه دسترسی به داده های خود احتیاج داشتیم. آخرین مرحله قبل از استفاده از این مدل، مشخص کردن Connection String برای ایجاد دیتابیس از روی آن است که می توانید در web.config آن را به صورت زیر مشخص کنید :

<connectionStrings><br />
 <add name="MyBlogPlatform"  connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=MyBlogPlatform;Integrated Security=True"  providerName="System.Data.SqlClient"  />

EF Code first به صورت پیش فرض به دنبال رشته اتصالی در فایل web.config می گردد که با کلاس Context شما همنام باشد. چون کلاس Context ما در این مثال MyBlogPlatform است، EF هم به دنبال رشته اتصالی به همین نام خواهد گشت و از آن برای ایجاد دیتابیس یا اتصال به دیتابیس موجود استفاده خواهد کرد. برای اینکه مطمئن شویم کارمان مشکلی ندارد کدی برای ایجاد یک موجودیت بلاگ در دیتبایس در مکان مناسب (مثل کلیک یک دکمه در صفحه) می نویسیم :

MyBlogPlatform blogPlatform = new MyBlogPlatform();<br />
 Blog blog = new Blog()<br />
 {<br />
 Title = "Farasun",<br />
 ShowInSearchEngines = true,<br />
 Description = "A blog about programming"<br />
 };<br />
 blogPlatform.Blogs.Add(blog);<br />
 blogPlatform.SaveChanges();<br />
 

در این نقطه کار ما به پایان رسیده و شما قادر خواهید بود که با مدل خود کار کنید. EF تمام کارهای مربوط به دیتابیس را انجام خواهد داد و شما فقط باید بر روی قوانین تجاری و رابط کاربری اپلیکیشن خود وقت بگذارید. به طور مثال برای کوئری گرفتن توسط LINQ می توانیم چنین کدی برای مدل خود بنویسیم :

MyBlogPlatform myBlogPlatform = new MyBlogPlatform();<br />
 var query = from x in myBlogPlatform.Posts<br />
 where x.Title.Contains(“Entity Framework”)<br />
 select x;<br />
 

اگر سری آموزش های Castle ActiveRecord در این وبلاگ را دنبال کرده باشید، با این پست غریبه نبوده اید. اینطور که به نظر می رسد تیم Entity Framework راه درستی برای ادامه توسعه این پروژه انتخاب کرده و در آینده ای نزدیک باید شاهد قابلیت های بیشتری در جهت بهبود کارایی این ORM باشیم.

گذاشتن محدودیت برای برنامه نویسان… اما به چه قیمتی!

گذاشتن محدودیت های مختلف برای برنامه نویسان از مهمترین دغدغه های اکثر مدیران شرکت های نرم افزاری در ایران بوده و هست. برنامه نویسی یک شغل بسیار متفاوت است که نمی توان با راهکارهای مدیریتی شغل های دیگر بر روی آن مدیریت داشت و موفق شد. کسی که قرار است بر روی چندین برنامه نویس و مهندس نرم افزار مدیریت کند خودش حتماً باید از زوایا و جزئیات این کار کاملاً آگاه باشد. به علت تفاوت این شغل با شغل های دیگر، نمی توان همان محدودیت هایی که برای کارمندان دیگر شغل ها در یک شرکت گذاشته می شود و معمولاً جواب می دهد را برای برنامه نویسان گذاشت و جواب گرفت.

به عنوان کسی که در حال حاضر به عنوان یک برنامه نویس کار می کند در این مطلب در مورد مهمترین محدودیت هایی که برای برنامه نویسان گذاشته می شود بحث خواهم کرد. شما هم اگر برنامه نویس هستید می توانید در قسمت نظرات این مطلب یا در وبلاگ خود در این مورد بنویسید. اگر مدیر شرکت نرم افزاری هستید در مورد این محدودیت ها در شرکت خود بنویسید و اگر مخالف هستید حتماً نظر مخالف خود را بیان کنید تا به یک نتیجه گیری خوب در آخر برسیم.

محدودیت دسترسی به اینترنت

در اکثر شرکت ها و مخصوصاً شرکت های نرم افزاری که به اینترنت نیاز دارند، این سئوال پیش می آید که آیا باید بر روی دسترسی اینترنت کارمندان محدودیت اعمال کرد یا نه. معمولاً اکثر محدودیت های اینترنتی شرکت ها بر روی وب سایت های شبکه های اجتماعی، مسنجرها، ایمیل ها و وب سایت های خبری و بلاگ های شخصی است. در مملکت ما که اکثر شبکه های اجتماعی بسته هستند و نیازی به اعمال محدودیت در سطح شرکت برای این وب سایت ها وجود ندارد. اما در مورد مسنجر ها، سرویس های ایمیل و وب سایت های خبری معمولاً محدودیت هایی اعمال می شود. در بعضی شرکت ها این محدودیت با استفاده از ابزارهای پیشرفته و تقریباً سنگین است و در برخی دیگر سخت گیری زیادی در مورد آن نمی شود اما می توان گفت در اکثر شرکت های نرم افزاری ایران در مورد استفاده از اینترنت برای نیروی فنی خود محدودیت می گذارند. دلیل این کار هم مشخص است، می خواهند برنامه نویسان به جای وقت تلف کردن در وب سایت های غیر مرتبط با کار، کارایی بالاتری داشته باشند. من به عنوان یک برنامه نویس با این ایده کاملاً مخالفم. با محدود کردن دسترسی برنامه نویسان به اینترنت نمی توان به کارایی بالاتر رسید. باید قبول کرد که برنامه نویسی شغلی بسیار متفاوت از شغل های دیگر است. کسی که می خواهد یک شرکت نرم افزاری را با چند برنامه نویسی اداره کند نباید تفکرش با مدیران دیگر یکی باشد. برنامه نویسی امروز بدون داشتن دسترسی به اینترنت امکان پذیر نخواهد بود.

می توان اینطور نتیجه گرفت که باید وب سایت های مرتبط با برنامه نویسی را آزاد گذاشت اما وب سایت های غیر مرتبط و سرویس های وب مثل ایمیل، مسنجر و شبکه های اجتماعی را فیلتر کرد. خب اینکه مسلم است وب سایت هایی مثل MSDN یا StackOverFlow باید برای برنامه نویسان قابل دسترس باشند، اما به نظرم بقیه وب، مثل شبکه های اجتماعی و مسنجرها نیز باید برای برنامه نویسان قابل دسترس باشند. می پرسید چرا؟ به این دلیل که اکثر برنامه نویس ها رابطه هایی دارند که می تواند هنگام کار به آن ها کمک کنند. به طور مثال من می توانم در مورد مشکلی که دارم در مسنجر از دوست برنامه نویسم کمک بخواهم یا ایده جدیدی برای حل مشکلم در یک گروه برنامه نویسی در فیس بوک بدست بیاورم. از جی میل می توانم برای ارتباط های کاری و رد و بدل کردن فایل هایم استفاده کنم. در مورد بلاگ ها هم همینطور. اکثر وبلاگ های برنامه نویسان مطرح به صورت وبلاگ شخصی هستند. ممکن است راه حلی که من بدنبال آن هستم در یکی از همین وبلاگ های شخصی باشد که برایم قابل دسترس نیست.

در مورد وب سایت های کاملاً غیر مرتبط با کار هم با اعمال محدودیت مخالفم. باز هم تکرار میکنم که برنامه نویسی با دیگر شغل ها تفاوت بسیاری دارد. خواندن یک مطلب کاملاً غیر مرتبط با کار می تواند ذهن من را به عنوان یک برنامه نویس رفرش کند تا بتوانم دوباره با ذهنی پاک بر روی مساله موجود تمرکز کنم و کارم را به اتمام برسانم. در این مورد تحقیق علمی هم وجود دارد که یک نمونه از آن ها را می توانید اینجا بخوانید.

محدودیت ساعت ورود و خروج

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

محدودیت صحبت با تلفن شخصی

این محدودیت شاید بهترین و موثرترین محدودیتی باشد که شما می توانید برای برنامه نویسان تان قرار دهید. به عنوان یک برنامه نویس هیچ چیز بیشتر از زنگ تلفن همراهم حواسم را هنگام کار پرت نمی کند. معمولاً جواب تلفنم را هنگام کد نویسی نمی دهم. بهترین حالت این است که در زمان کار از برنامه نویسان بخواهید که گوشی های خود را خاموش کنند و به هنگام نهار و استراحت در این مورد آزاد باشند. هر چند باز هم باید تلفن های ضروری را استثنا دانست و سخت گیری در این مورد نباید داشت زیرا برنامه نویسی که منتظر یک تماس تلفنی مهم و ضروری است نمی تواند به خوبی کار کند و همه حواسش به تلفنش خواهد بود.

محدودیت زمان استراحت

به عنوان یک برنامه نویس نمی توانم بیشتر از دو ساعت به صورت مداوم کدنویسی کنم و به مانیتور چشم بدوزم. باید درک کرد که یک برنامه نویس با یک تایپیست فرق می کند، و برای هر خطی که تایپ می کند ابتدا باید فکر کند. بهترین حالت این است که به صورت دوره ای مثلاً هر یک ساعت، 10 دقیقه به ذهن استراحت داد تا برای ادامه کار ذهن خسته نباشد. در این 10 دقیقه می توان چای یا قهوه نوشید و با همکار در حال استراحت خود گپ زد. برای خودم خیلی پیش آمده که زمانی که ذهنم بر روی یک مشکل متمرکز شده است، در زمان استراحت ایده جدیدی برای رفع مشکل به ذهنم خطور کرده و کارایی ام بالاتر رفته است. بعد از هر یک ساعت کار 10 دقیقه از میز و مانیتورتان دور شوید، قهوه یا چای بنوشید، قدمی بزنید، زیر آفتاب بروید و ذهن تان را رفرش کنید. زمانی که به سختی بر روی یک موضوعی کار می کنید و جواب نمی گیرید و ممکن است با 10 دقیقه استراحت ذهنی، کل قضیه از دستتان خارج شود می توان با کمی قدم زدن و فکر کردن ایده های جدیدی برای رفع مشکل پیدا کرد. در زمان استراحت می توان حتی مطالب غیر کاری را در وب مطالعه کرد تا ذهن برای ادامه کار خلوت و آماده شود.

این را بخاطر داشته باشید که برنامه نویسی که به طور مداوم کدنویسی می کند و به مانیتور خیره است نه تنها کارایی بالاتری ندارد بلکه مطمئن باشید کیفیت کارش از برنامه نویسی که هم کار می کند و هم استراحت، پایین تر است. می توان با استراحت های دوره ای در حین کار، مثل نوشیدن قهوه، خوردن میان وعده، گپ زدن در مورد مطالب غیر کاری و خواندن یک مطلب خنده دار به همراه همکاران در حال استراحت، کارایی را بالا برد. سخت کار کردن هیچ ربطی به 4-5 ساعت پشت سر هم کد نویسی و نشستن و خیره شدن به مانیتور ندارد! درست کار کردن مهم است.

محدودیت گوش دادن به موزیک

گوش دادن به موزیک در حین کار برای اشخاص به اصطلاح Knoledge Worker مثل نویسندگان و برنامه نویسان می تواند مفید باشد. من خودم به عنوان یک برنامه نویس زمانی که در حین کار به موزیک گوش میدهم از زمانی که در سکوت برنامه نویسی می کنم، کارایی بالاتری دارم. گوش دادن به موزیک با هدفون مخصوصاً زمانی که تیم تولید و پشتیبانی و منشی و بازاریاب یکجا هستند و سر و صدا زیاد است، حتماً کارایی یک برنامه نویس را افزایش می دهد و کمک می کند تا برنامه نویس تمرکز بیشتری بر موضوع کارش داشته باشد. هرچند گوش دادن به موزیک در حین کار یک موضوع کاملاً سلیقه ای است، اما حتی برای کسانی که از این کار خوششان نمی آید هم تاثیر مثبت به همراه دارد، فقط آن ها باید این موضوع را قبول کنند. گوش دادن به موزیک هم می تواند باعث پرت شدن حواس در حین کار شود و هم می تواند به شما کمک کند تا بر روی کار خود تمرکز بیشتری داشته باشید. این باید بستگی به خود برنامه نویس داشته باشد که آیا می تواند با گوش دادن به موزیک کارایی خود را بالاتر ببرد یا خیر؟

گوش دادن به موزیک بوسیله هدفون در حین برنامه نویسی مثل این است که در اتاق خود را ببندید و در آرامش کار خود را انجام بدهید حتی در زمانی که در یک جای شلوغ و پر استرس قرار دارید. روی هر چیزی محدودیت قرار می دهید به هیچ وجه سعی نکنید بر روی گوش دادن موزیک در مورد برنامه نویسان محدودیت قرار دهید!

نتیجه

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

farasun.wordpress.com

خواندن مطلب مرتبط : یک محیط سفارشی شده; تمام چیزی که یک برنامه نویس می خواهد!

Subcribe to Farasun feedمشترک فراسان شويد

پ.ن : ایده این مطلب از مطلب آقای آواژ با عنوان «تفکیک مسائل شخصی از محیط کار» به ذهنم خطور کرد.

نگهداری تاریخچه تغییرات اطلاعات در یک دیتابیس

چند وقتی است درگیر پروژه ای شدم که ذخیره تغییرات برخی داده های اساسی سیستم از نیازهای اصلی آن است. به این صورت که اگر اطلاعات پایه دچار تغییرات شد، باید نسخه قبلی این اطلاعات در جایی ذخیره شود که بعداً برای گزارش گیری مورد استفاده قرار گیرد. به صورت معمول و در سیستم های معمولی رسم بر این است که اگر داده ای در یک جدول دیتابیس تغییر کرد دیگر تغییر کرده و اطلاعات قبلی آن قابل ردگیری نیست. ساده ترین راه حلی که به ذهن می رسد، گرفتن نسخه پشتیبان از دیتابیس به صورت دوره ای است. اما این روش برای این کار روش مناسبی نیست. ممکن است داده ها در طول یک دوره پشتیبان گیری بارها تغییر کنند، آن وقت تنها آخرین داده های تغییر داده شده را خواهیم داشت نه کل تغییرات را. به این اضافه کنید حجم زیادی که ممکن است فایل های Backup داشته باشند.

خوشبختانه این مشکلی نیست که برای اولین بار در جهان ما با آن برخورد کرده باشیم. در سطح اینترنت بحث های زیادی در این مورد وجود دارد و راه حل های مختلفی در مورد آن ارائه شده است. قبل از ما نرم افزارهای مختلفی مثل سورس کنترل ها و وب سایت معروف Wikipedia مکانیزم هایی برای ذخیره تغییرات داده های مهم خود پیاده سازی کرده اند. پس این نیاز، به هیچ وجه نیاز غیر معقولی نیست. کاربر نیاز دارد بداند در یک بازه زمانی خاص، موجودیت مورد نظرش چه مقداری داشته است و ما باید این امکان را برایش پیاده سازی کنیم.

یک روش طراحی دیتابیس به نام Point in Time Architecture وجود دارد که به صورت مخصوص برای حل چنین مشکلی بکار می رود. این روش طراحی تضمین می کند که همیشه تصویری از اطلاعات گذشته را در خود نگهداری کند تا هر گاه نیازی به اطلاعات گذشته بود، در اختیار ما قرار بدهد. در این روش طراحی هیچ گاه رکوردها به صورت فیزیکی آپدیت یا حذف نخواهند شد و فقط flagهایی برای علامت گذاری بر روی رکوردهای تغییر داده شده قرار می گیرد. در این روش، ساختار دیتابیس باید طوری طراحی شود که دیتابیس به ازای هر رکورد بتواند به سئوالات زیر پاسخ دهد :

  • رکورد چه موقع و توسط چه کسی Insert شد؟
  • رکورد چه موقع و توسط چه کسی Update شد؟
  • در یک تاریخ خاص اطلاعات رکورد چگونه بوده است؟

برای پاسخ به این سئوالات باید یکسری فیلد کنترلی داشته باشیم :

  • CreatedDate : تاریخ ساخته شدن رکورد برای اولین بار
  • ModifiedDate : تاریخی که اطلاعات رکورد تغییر داده می شوند
  • UserID : کاربری که اطلاعات را تغییر می دهد

tuple versioningبرای پیاده سازی چنین روشی می توان دو جور عمل کرد. روش اول این است که هر گاه کاربر خواست اطلاعات را تغییر دهد، به جای عمل Update ما یک عمل Insert انجام دهیم و اطلاعات قبلی را با یک فیلد کنترلی آرشیو شده محسوب کنیم. در این روش باید یک فیلد ModifiedDate داشت که هر زمان رکورد ویرایش شد مقداردهی شود. رکوردی که فیلد ModifiedDate آن برابر null باشد، رکورد جاری ما خواهد بود. این روش Tuple Versioning نام دارد که مکانیزمی برای ذخیره حالت فعلی یک رکورد به علاوه حالت های گذشته آن در یک جدول است. این روش برای زمانی که امکان تغییرات در رکوردهای جدول کم باشد بسیار مناسب است. در صورت زیاد بودن امکان تغییرات یک رکورد، باعث حجیم شدن جدول می شود و کارایی را پایین می آورد.

روش دوم ایجاد یک جدول History برای هر جدولی است که می خواهیم تغییرات داده های آن را پیگیری کنیم. به این صورت که برای هر جدول که نیاز به ذخیره تغییرات آن داریم یک جدول History می سازیم که هنگام تغییر هر یک از رکوردهای جدول اصلی، یک رکورد به جدول History متناظر آن اضافه می کنیم و یکسری اطلاعات اضافه مثل تاریخ تغییر و کاربر تغییر دهنده را همراه با آن ذخیره می کنیم.

History Tableهمانطور که در شکل بالا می بینید، برای نگهداری تاریخچه تغییرات قیمت یک محصول، یک Table جداگانه میسازیم و چند فیلد کنترلی به آن اضافه می کنیم. در اینجا فیلدهای ModifiedDate تاریخ تغییر قیمت محصول، SalesPrice قیمت محصول در زمان تغییر و UserID مشخص کننده کاربری است که قیمت محصول را تغییر داده است.

مزیت اینگونه طراحی دیتابیس در هنگان گزارش گیری مشخص می شود. با این طراحی، کاربر می تواند تمام تغییرات داده های مهم خود در طی زمان های مختلف را مشاهده کند.

چرا NHibernate انتخاب خوبی به عنوان یک ORM است؟

در مطلب قبل دلایلی برای استفاده از ORM در دات نت فریم ورک برای دسترسی به داده ها و کار با دیتابیس معرفی شد. در این مطلب به معرفی NHibernate و دلایلی برای استفاده از آن به عنوان یک ORM مناسب برای دات نت فریم ورک پرداخته خواهد شد. NHibernate پیاده سازی ORM معروف دنیای جاوا یعنی Hibernate برای پلت فرم دات نت است که به صورت گسترده ای مورد استفاده توسعه دهندگان دات نت در سراسر دنیا قرار گرفته است. NHibernate آزاد و کد باز است و وظیفه اش مانند ORMهای دیگر نگاشت کلاس های شیء گرا به جدوال یک دیتابیس است.

nhibernate logoدر ادامه مطلب با مزیت های NHibernate به عنوان یکی از بهترین ORMهای موجود برای پلت فرم دات نت آشنا می شوید. البته تمام مزیت هایی که در مطلب قبل در مورد یک ORM ذکر شد، در مورد NHibernate نیز صحت دارند که دیگر از ذکر آن ها در این مطلب صرف نظر شده است.

کد باز است : شاید به نظر بعضی ها اوپن سورس بودن مزیت محسوب نشود، اما کد باز بودن NHibernate باعث شده تا این پروژه خیلی زود پیشرفت کند و به پر استفاده ترین و به روز ترین ORM پلت فرم دات نت تبدیل شود. در حال حاضر افراد زیادی به صورت تمام وقت و نیمه وقت بر روی توسعه NHibernate کار می کنند و از این ORM در بسیاری از پروژه های کد باز و تجاری استفاده می شود. حداقل برای من، کد باز بودن NHibernate مزیت بسیار مهمی محسوب می شود.

منابع آموزشی زیادی دارد : NHibernate دارای مستندات قوی و جامعه کاربری بزرگی است. یادگیری آن به لطف مستندات کامل و کتاب هایی که در مورد آن نوشته شده، آسان است. کاربران بسیاری در وب سایت های مختلف حاضر به پاسخگویی سئوالات شما در مورد NHibernate خواهند بود و برای تمام مشکلات شما راه حل های بسیاری در سطح اینترنت وجود دارد. با جستجوی کوچکی در اینترنت می توانید کتاب های مناسبی برای یادگیری NHibernate دانلود کنید!

واقعاً از چند دیتابیس پشتیبانی می کند : شما فقط به SQL Server محدود نخواهید بود و تقریباً می توانید از هر دیتابیسی برای ذخیره داده های برنامه خود استفاده کنید.  NHibernate در حال حاضر از DBMSهای معروف و پر کاربرد مثل Oracle, SQL Server و MySql و چند دیتابیس دیگر پشتیبانی واقعی می کند. این در حالی است که Entity Framework مایکروسافت در حال حاضر به صورت رسمی فقط از SQL Server پشتیبانی می کند.

از زبان HQL پشتیبانی می کند : زبان HQL یک زبان پرس و جوی پیشرفته است که در پروژه Hibernate جاوا به صورت وسیع مورد استفاده قرار می گیرد. با استفاده از این زبان می توانید کوئری های پیچیده را بر روی دیتابیس مورد نظر خود اجرا کنید.

امتحان خود را پس داده است : در حال حاضر NHibernate به صورت گسترده ای در پروژه های مختلف کد باز و تجاری مبتنی بر پلت فرم دات نت مایکروسافت مورد استفاده قرار می گیرد. تجربه های بسیار خوبی از استفاده از NHibernate به عنوان ORM در پلت فرم دات نت وجود دارد. در واقع NHibernate مطمئن ترین و با اعتبار ترین ORM برای پلت فرم دات نت مایکروسافت است.

انجام تغییرات را آسان می کند : از آنجا که موجودیت های پروژه را خودتان مدل می کنید و بر روی آن ها کنترل دارید، انجام تغییرات بر روی مدل و ایجاد دیتابیس از روی آن با NHibernate بسیار آسان است. انجام تغییرات بر روی مدل برنامه با مهارت های یک برنامه نویس معمولی دات نت قابل انجام است و نیازی نیست برای تغییر در مدل برنامه و در نتیجه تغییر در دیتابیس یک حرفه ای باشید. این را هنگام توسعه اولین برنامه خود با NHibernate شدیداً درک خواهید کرد!

کتابخانه های کمکی مناسبی دارد : پس از یادگیری NHibernate متوجه خواهید شد که می توان بسیاری از کارها را با کتابخانه های کمکی که برای آن نوشته شده، سریع تر و آسان تر انجام داد. به طور مثال می توان از Fluent NHibernate برای انجام اعمال Mapping به جای نگاشت بر اساس فایل های XML استفاده کرد. کتابخانه  Castle ActiveRecord با اضافه کردن لایه ای بر روی NHibernate کاری می کند که شما بدون درگیر شدن با پیچیدگی های NHibernate از آن به راحتی استفاده کنید. کتابخانه ای برای اضافه کردن Validation و کتابخانه ای برای اجرای کوئری های Linq بر روی آبجکت های NHibernate نیز موجود است.

کارایی بالایی دارد : به عنوان یک ORM از کارایی مناسبی برای انجام عملیات های سنگین بر روی دیتابیس برخوردار است. البته این کارایی مناسب در صورتی است که شما NHibernate را به درستی تنظیم و از آن استفاده کنید. ویژگی هایی مثل Second Level Caching، Multi Query و Batch Select که باعث کاهش ایجاد اتصال ها به دیتابیس و در نتیجه افزایش Performance می شوند در NHibernate وجود دارند و شما کافیست تا از آن ها در مواقع مناسب استفاده کنید.

قابلیت تست پذیری بالایی دارد : به علت جدا کردن دامین مدل برنامه از لایه های دیگر برنامه، قابلیت تست پذیری اپلیکیشن هایی که بر اساس NHibernate توسعه می یابند بسیار بالاست. شما می توانید مدل برنامه خود را مورد آزمایش های واحد قرار دهید و از صحت عملکرد آن ها اطمینان حاصل نمایید.

farasun.wordpress.com

اگر دلیل دیگری برای استفاده از NHibernate به عنوان یک ORM مناسب برای دات نت فریم ورک سراغ دارید، در فرم نظرات این مطلب با ما به اشتراک بگذارید.

10 دلیل برای استفاده از ORM در دات نت فریم ورک

ORM یک تکنیک برنامه نویسی برای تبدیل مدل رابطه ای یک دیتابیس به مدل شیء گرا و بالعکس می باشد که در حال حاضر مورد توجه بسیاری از توسعه دهندگان نرم افزاری قرار دارد. استفاده از ORMها مزایای بسیاری دارد و در بسیاری موارد کار توسعه را آسان تر و لذت بخش تر خواهد کرد. برای دات نت فریم ورک ORMهای کدباز و تجاری زیادی وجود دارد که از این جمله می توان به ADO.NET Entity Framework و NHibernate اشاره نمود. من به شخصه از Entity Framework در یک پروژه واقعی استفاده کردم و تمام مزایایی که قبلاً در مورد یک ORM خوانده بودم را در واقعیت دیدم. در این مطلب به 10 دلیل برای استفاده از یک ORM در یک پروژه مبتنی بر دات نت فریم ورک اشاره خواهم کرد که به شخصه آن ها را تجربه کرده ام.

1- افزایش سرعت توسعه : طراحی لایه دسترسی به داده ها در یک برنامه تجاری معولاً زمان قابل توجهی را به خود اختصاص می دهد و کارهای تکراری مثل درج، به روز رسانی، حذف و خواندن رکوردهای دیتابیس به وفور در آن یافت می شود. استفاده از یک ORM می تواند زمان طراحی لایه دسترسی به داده ها را کاهش دهد یا حتی در مواردی نیاز شما به این لایه را از بین ببرد و شما را از نوشتن کدهای تکراری برای انجام اعمال بر روی دیتابیس راحت کند. اگر وقت زیادی صرف نوشتن کوئری های SQL به صورت رشته ای برای خواندن رکوردها و استفاده از آبجکت های ADO.NET برای درج، به روز رسانی یا حذف داده های یک دیتابیس می کنید، بهتر است در رویه برنامه نویسی خود تجدید نظر کنید و بقیه مزایای استفاده از یک ORM را تا انتها بخوانید!

2- رعایت الگوی طراحی شیء گرا : تفاوت ماهیت دیتابیس های رابطه ای با الگوی شیء گرا همیشه برای برنامه نویسان معضل بزرگی بوده و هست. کار اصلی ORM این است که جدوال رابطه ای یک دیتابیس را به کلاس های شیء گرا و بالعکس تبدیل کند و مدل سازی های مورد نیاز را به صورت استاندارد انجام دهد. هرچند در این روش نمی توان از برخی مفاهیم مهم طراحی شیء گرا مثل ارث بری یا چند ریختی استفاده کرد اما برنامه نویس را مجبور خواهد کرد تا حداقل قوانین های طراحی شیء گرایی را در پروژه خود لحاظ کند. استفاده از الگوی طراحی OOP باعث کاهش پیچیدگی پروژه و آسان تر شدن نگهداری کد و اعمال تغییرات بر روی آن خواهد شد.

3- کاهش پیچیدگی پروژه : شاید در ابتدا استفاده از یک ORM برای طراحی یک پروژه بزرگ ترسناک به نظر برسد! اما در واقع ORM برای کاهش پیچیدگی توسعه یک پروژه بوجود آمده است. استفاده از کلاس های شیء گرا برای کار با ساختار پایگاه داده برای یک برنامه نویس دات نت بسیار راحت تر از سر و کله زدن با کوئری های SQL برای رسیدن به نتایج مورد نظر یا انجام عملیات بر روی دیتابیس خواهد بود. در واقع کدهای مورد استفاده در پروژه ای که با یک ORM توسعه داده شده است به مراتب خواناتر از پروژه های دیگر است و حتی یک فرد غیر برنامه نویس نیز منظور کد را خواهد فهمید.

4- راحت شدن از دست SQL : برای کار کردن با جداول یک پایگاه داده زبان SQL زبان بی نقصی است، اما زمانی که قرار باشد از آن در یک زبان برنامه نویسی شیء گرا مثل سی شارپ استفاده شود، واقعاً عذاب آور خواهد بود. فرض کنید در تمام پروژه خود از دستورات SQL در متغیرهای string استفاده کرده اید، حال با تغییر نام یک فیلد بایستی به دنبال رشته نام فیلد مورد نظر، کل پروژه را بگردید و رشته جدید را جایگزین آن کنید و این کار به صورت خودکار انجام نخواهد شد. کامپایلر هیچ نوع کنترلی بر روی رشته های  SQL ندارد و یک اشتباه تایپی می تواند باعث ایجاد خطای در حال اجرا شود. استفاده از ORM می تواند شما را شر SQL راحت کند!

5- طراحی استاندارد لایه دسترسی به داده ها : در پیاده سازی ORMهای موجود تمام تجربه های موفق لحاظ شده اند و در نتیجه کدهای تولید شده توسط آن ها کاملاً بهینه و استاندارد هستند. ORM باعث می شود تا شما و بقیه اعضای تیم از یک استاندارد خاص برای طراحی لایه دسترسی به داده های خود پیروی کنید و در نتیجه بازدهی بهتری را شاهد باشید. این مزیت در آخر باعث بوجود آمدن یک ساختار مناسب در لایه دسترسی به داده های پروژه شما خواهد شد.

6- امکان استفاده از LINQ : در دات نت فریم ورک می توانید از زبان LINQ برای اجرای کوئری های مختلف در هنگام استفاده از یک ORM بهره ببرید. با این کار کامپایلر کنترل کاملی بر روی کوئری های نوشته شده دارد و تمام خطاها را شناسایی و گزارش خواهد کرد. به علاوه کوئری های نوشته شده در این حالت از خوانایی بسیار بالاتری برخوردار خواهند بود و می توانید از قابلیت های IntelliSense ویژاول استادیو برای بالا بردن سرعت کدنویسی و کاهش خطاهای انسانی بهره ببرید.

7- ORMها آزمایش خود را پس داده اند : در حال حاضر تعداد بسیار زیادی از پروژه های اوپن سورس پلت فرم دات نت بر پایه یک ORM توسعه یافته اند. با یک جستجوی کوچک می توانید لیست بلند بالایی از این پروژه ها را مشاهده کنید. تجربه های خوب بسیار زیادی هم از پروژه های تجاری که از ORM برای دسترسی به داده ها استفاده کرده اند در اینترنت وجود دارد. این نشان می دهد که ORMها آزمایش خود را پس داده اند و برای استفاده در پروژه های واقعی به اندازه کافی قابل اعتمادند.

8- نگهداری از کد و تغییر آن در دراز مدت آسان تر می شود : به علت پشتیبانی ORMها از الگوی طراحی شیء گرا و دیگر الگوهای طراحی در توسعه نرم افزار و تولید کدهای استاندارد، نگهداری از کدهای نوشته شده و تغییر آن ها در طولانی مدت بسیار آسان تر خواهد شد. کدهای نوشته شده بر مبنای یک ORM معمولاً بسیار واضح هستند و تغییر آن ها اگر به صورت استاندارد نوشته شده باشند، اصلاً سخت نخواهد بود.

9- استفاده از قابلیت Refactoring : فرض کنید نیاز دارید تا نام چند فیلد یا جدول را در دیتابیس خود تغییر دهید. اگر از ADO.NET و کدهای SQL برای طراحی لایه داده های خود استفاده کرده باشید، برای انجام این تغییرات در کدهای خود نمی توانید از قابلیت Refactoring ویژوال استادیو استفاده کنید تا به صورت اتوماتیک این کارها انجام شود. اما با استفاده از یک ORM، تغییر دادن یک موجودیت باعث به روز رسانی تمامی ارجاع های آن موجودیت در کل پروژه توسط قابلیت Refactoring ویژوال استادیو خواهد شد. این قابلیت می تواند خطاهای انسانی را فوق العاده کاهش و سرعت توسعه را افزایش دهد.

10 – عدم وابستگی به یک دیتابیس خاص : هر چند این نکته در مورد تمام ORMهای مخصوص دات نت فریم ورک درست نیست، اما در حال حاضر ORMهای خوبی مثل NHibernate و Entity Framework از چندین دیتابیس پر استفاده پشتیبانی می کنند. البته EF در حال حاضر به صورت رسمی فقط از SQL Server پشتیبانی می کند!

farasun.wordpress.com

توصیه می شود مطالبی که قبلاً دوستان در این مورد نوشته بودند را مطالعه کنید :

farasun.wordpress.com

عناوین دیگر برای این نوشته : چرا باید از یک ORM در دات نت فریم ورک استفاده کرد؟ | مزیت های استفاده از ORM در دات نت فریم ورک