Experiences with NuGet, Autofac and Autofac WCF

Days ago I started to work on a new multi-tenant WCF,EF,MVC project. A Visual Studio solution consisted of some projects. Data layer was handled by EF, communication between pieces of software was handled with WCF and front end was baked with ASP.NET MVC. Additionally all references were made via NuGet.

During this project I faced several problems. First of them was Autofac. Autofac is a nice .Net IoC library but I had some problems with it. I never knew that Autofac WCF is a separate assembly. One reason was that I thought NuGet will download all references for me. I spent many time to configuring Autofac WCF but because I had no reference to Autofac WCF I thought it is because my version of Autofac is old. So tried to compile it.

Another problem with Autofac was that documentations has a lot content on hosting a WCF service via Autofac but many poor content on how to consume a WCF service via Autofac. Because of this I was confused how to consume a WCF service via Autofac.

Initializing Autofac with MVC was not so problematic. Just using sample codes. ASP.NET MVC is great on receiving instances on constructors.

NuGet bothered a little. It was because I was not very familiar with it. I was using it incorrectly.

Entity Framework was not very problematic in first steps. Hope to not have no problems with it as a NHibernate fun.

‫اولین تجربه با BugNET

BugNET یک نرم‌افزار Issue Tracking کد باز است که با ASP.NET نوشته شده است. قبلاً در سایت آن چیزهای خوبی راجع به امکانات آن خوانده بودم. با این که IssueTracker.NET خیلی رایج‌تر از BugNET است اما امکانات BugNET بیشتر و بهتر به نظر می‌رسید. به همین خاطر تصمیم گرفتم آن را نصب کرده و امکانات آن را از نزدیک ببینم.

خوشبختانه با تعریف اولین پروژه در BugNET فهمیدم که BugNET امکانات مدیریت پروژه را تا حد خوبی پوشش می‌دهد. چیزی که فکر می‌کردم به غیر از جیرا در هیچ نرم‌افزار Issue Tracking دیگری وجود نداشته باشد. BugNET هم امکان تعریف Category و Milestone را دارد و هم امکان استفاده از Issue Typeهایی غیر از نوع باگ. علاوه بر اینها امکان تعریف دسترسی‌ها، تعریف Queryهای مختلف و نگهداری History ایشوها را هم داراست. به همین دلیل می‌توان از آن به عنوان یک نرم‌افزار مدیریت پروژه هم استفاده کرد.

یکی دیگر از امکانات خوب BugNET امکان تعریف نوع Issueها، نوع Statusها، نوع اولویت‌ها و نوع Resolutionهای دلخواه بر حسب نیاز است. در واقع شما هر وقت که یک پروژه جدید تعریف می‌کنید خودتان باید تک تک انواع Issueها و غیره را با نسبت دادن اسم مناسب و تخصیص icon مناسب تعریف کنید. به این ترتیب BugNET را می‌توان کاملاً Customizable نامید.

به نظر می‌آید BugNET موارد امنیتی را به خوبی رعایت کرده باشد. چون هم Roleهای مختلفی را می‌توان تعریف کرد و هم به ازای هر Role می‌توان دسترسی‌های خیلی مختلفی را تعریف کرد. هر پروژه یا هر Issue را به دلخواه می‌توان به صورت غیر خصوصی تعریف کرد. امکان ثبت نام کاربران به طور خودکار هم وجود دارد. علاوه بر اینها ظاهراً می‌توان با استفاده از OpenID به BugNET لاگین کرد. همه اینها در کنار هم به شما امکان می‌دهد تا بتوانید BugNET را هم در محیط اینترانت و هم در محیط اینترنت مورد استفاده قرار دهید.

نصب BugNET یکی دو تا قلق کوچک دارد. BugNET نیاز به فریمورک 3.5 دارد. برای دیتابیس هم احتیاج به MS SQL 2005 و بالاتر و یا نسخه Express همان دیتابیس‌ها دارد. به هنگام نصب BugNET باید صفحه Install.aspx را اجرا کنید. در همین حین به چند خط web.config گیر داده می‌شود. من آنها را کامنت کردم و هیچ مشکل خاصی به وجود نیامد. قسمت بد BugNET تنظیم دسترسی‌ها است. در بیشتر برنامه‌های مشابه کافی است که به یکی دو تا فولدر خاص مثل App_Data دسترسی full داده شود. ولی در مورد bugNET باید به کل فولدری که فایل‌ها و فولدرهای bugNET در آن قرار دارد دسترسی full دارد. به همین علت نمی‌توان BugNET را در root یک domain یا حتی sub domain نصب کرد. چون ابزارهای سروری مثل Plesk اجازه تغییر دسترسی فولدرهای حاوی root مثل httpdocs را نمی‌دهند. متاسفانه در BugNET نمی‌توان از تقوم هجری استفاده کرد. مشکل راست به چپ نویسی هم مثل همیشه وجود دارد. مشکل راست به چپ نویسی را می‌توان با استفاده از کاراکترهای کمکی صفحه کلید استاندارد ۹۱۴۷ تا اندازه‌ای حل کرد. البته BugNET کدباز بوده و می‌توان در صورت علاقه کل آن را فارسی کرد.

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

یکی از مهم‌ترین جنبه‌های روش‌های جدید مبتنی بر agile توسعه نرم‌افزار بر اساس نیاز محدود فعلی و تغییرات مداوم آن بر اساس تغییر نیازمندی‌های مشتری یا تغییر درک تیم از نیازمندی‌هاست. روش‌های جدید به ما می‌گویند هیچ چیزی را از همان اول به طور کامل نسازیم. اول یک تیکه کوچک از آن را به طور کامل بسازیم و بعداً در صورت نیاز آن را تغییر دهیم.

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

در همین راستا سعی کردم تغییر مداوم را در پروژه «کارویس» تمرین کنم. باید اذعان کنم آنقدرها هم سخت نبود. در واقع تغییر مداوم چیزی است که می‌توان تا اندازه‌ای به آن عادت کرد. یعنی اگر شما به این دیدگاه عادت کنید خود به خود در برنامه‌هایی که می‌نویسید موارد لازم را تا انداره‌ای رعایت خواهید کرد. خوشبختانه پیروی از الگوی تغییر مداوم در صورتی که اصولی انجام شود باعث افزایش سرعت در پیاده‌سازی تیکه تیکه‌های نرم‌افزار هم می‌شود.

یکی از موضوعاتی که سعی کردم در کنار «تغییر مداوم» تمرین کنم، انجام تست واحد (unit test) بود. باید صادق بوده و اعتراف کنم که متاسفانه در این زمینه تا این لحظه هیچ موفقیتی به دست نیاورده‌ام. انجام این کار سخت‌تر از آنی بود که فکر می‌کردم. به خاطر ماهیت «کارویس» نیاز به mocking زیادی بود که وقت آن را نداشتم. علاوه بر این در خیلی از موارد طراحی تست سخت‌تر از پیاده‌سازی آن بود. وسوسه شیطانی اختصاص وقت تست به توسعه را هم می‌توانید به فهرست دلایل اضافه کنید. هنوز هم در حال تلاش برای عادت کردن به unit testهای موثر در کارویس و دیگر پروژه‌ها هستم.

کاهش مشکلات خروج افراد از تیم

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

۱- پیاده‌سازی نرم‌افزار بر اساس نقشه و طرح معین و مکتوب نه آنچه که در ذهن افراد قرار دارد.
۲- به کارگیری اصول روز مهندسی نرم‌افزار و هر چیز دیگری که باعث بالا رفتن خاصیت Maintainability کد می‌شود.
۳- مستند سازی کد
۴- ممیزی کد و کیفیت آن توسط Lead تیم
۵- Code Review افراد تیم از همدیگر که باعث می‌شود هر کسی به غیر از کار خودش از کار دیگران هم خبر داشته باشد
۶- جابجایی عمدی افراد در تیم که اثری مشابه مورد قبل دارد.
۷- استفاده از روش‌های ساده برای حل مسئله. به این ترتیب لازم نیست نفر بعدی در کدهای پیچیده گم شود.
۸- استفاده از ابزارهای Issue Tracking که باعث می‌شود نفرات جدید بدانند چه باگ‌هایی وجود داشته و چطور برطرف شده‌اند.
۹- استفاده از ابزارهای Help Desk برای حفظ ارتباط با مشتری
۱۰- یک دست بودن تیم از لحاظ تکنولوژی‌های مورد استفاده. مثلاً این طور نباشد که یکی از ویژوال استودیو استفاده کند و دیگری از مونو.
۱۱- …

‫مزایای الگوی MVP

خیلی وقت پیش چیزهایی راجع به استفاده از الگوی MVP‌ در صفحات ASP.NET WebForm شنیده بودم. مزایایش را می‌دانستم و کمی هم امتحانش کرده بودم. اخیراً در یک پروژه وب کوچک ASP.NET WebForm از اون به طور کامل استفاده کرده و تمام مزایای آن را به طور عملی لمس کردم.

یکی از بهترین چیزهایی که MVP برای من داشت این بود که تقریباً به من اجازه نمی‌داد که در صفحات ASPX از کنترل‌های Data Aware مثل Grid و Form به صورت خودکار و markup استفاده کنم. به عبارت دیگر Data Binding و واگذار کردن همه چیز به DataSourceها ممنوع شده بود. این طوری من مجبور شدم همه عملیات مثل نمایش اطلاعات در صفحه یا خواندن اطلاعات از کنترل‌ها از طریق CodeBehind انجام دهم. خوبی این کار در این بود که جلوی بعضی خطاها را همان هنگام compile می‌گیرم. مثل اگر نام فیلدی را اشتباه تایپ کرده باشم یا تعداد پارامترهای دریافتی یک متود را رعایت نکرده باشم، همان زمان کامپایل خطا را می‌بینم. در حالت DataBinding خودکار نام فیلدها، متودها و اطلاعات پارامترها به صورت string غیر قابل کامپایل در فایل aspx/ascx قرار دارد و تا زمانی که صفحه در یک مرورگر باز نشود نمی‌توان متوجه خطا شد.

حس می‌کنم MVP قدرت تقسیم کار و کار تیمی را افزایش می‌دهد. چون همان کاری که همیشه در Codebehind انجام می‌شد، حتی با فرض این که دسترسی به دیتابیس و logic کار در یک لایه جداگانه انجام می‌پذیرد، را هم می‌توان به دو تیکه کاملاً مجزا تقسیم کرده و به افراد مختلف سپرد. این موضوع کار designerها (طراحی صفحات، گرافیک، جاوا اسکریپت) را هم ساده می‌کند. چون می‌توانند به صورت مستقل از برنامه‌نویس‌ها و بدون آن که مجبور باشند کار همدیگر را خراب کنند، با خیال راحت کارشان را انجام دهند. خوانا شدن کد برنامه، خصوصاً آنچه که در Presenter قرار داد، بخش دیگری از مزایای MVP است که من خودم با دستان خودم لمس کردم.

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

پ.ن.: به این لینک هم که توضیحاتی کلی راجع به مدل‌های MVP و مشابه MVP است نگاهی بیندازید.

اشتباهات دوران دانشگاه

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

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

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

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

۴- انتخاب C#‎ به جای جاوا.
آن اوایل دانشگاه همه ما با هم دلفی کار بودیم اما کمی بعد سر و کله دات‌نت و جاوا پیدا شد و خیلی‌ها از جمله خود من دلفی را فراموش و به سمت یکی از این دو سکو رفتیم. آن زمان خیلی با بحث Open Source و… آشنا نبودم و فکر می‌کردم چون جاوا کد باز است ممکن است خیلی رشد نکند. ولی چون مایکروسافت یک شرکت تجاری خیلی بزرگ است حتماً دات‌نت‎ موفق‌تر خواهد بود. البته گذر زمان نشان داد هر چند که دات‌نت‎ چندان شکست نخورد اما آنهایی که به سمت جاوا رفتند موفق‌تر بودند خصوصاً آنها که در ایران بودند. به عنوان مدرک می‌توانید تعداد پروژه‌های موفق در جاوا را مقایسه کنید با پروژه‌های موفق C#‎. به عنوان مثال Hibernate را. اگر نمونه کدها یا سواد آدم‌های جاوا کار را مقایسه کنید با نمونه کدهای C#‎ یا آدم‌های C#‎ کار متوجه می‌شوید که به طور نسبی جاوا کارها با سوادتر و کدهایی که می‌نویسند دقیق‌تر و اصولی‌تر است. در بازار کار هم برنامه‌نویس‌های جاوا محبوبیت بیشتری داشته و حتی میانگین حقوقی بالاتری هم دارند. به طور کلی به نظر می‌رسد در ایران شرکت‌های جاوایی تیم‌های قوی‌تر و برنامه‌نویس‌های بهتری داشته باشند تا شرکت‌های دات‌نتی.

۵- عدم استفاده مفید از سربازی
هر چند که سربازی را باید رفت چون همه می‌روند اما بنده به خاطری کوتاهی‌هایی که در بعضی زمینه‌ها و شبکه اجتماعی (در اینجا آشنا و پارتی) در طول دوران تحصیل کرده بودم نتوانستم امریه پیدا کنم. حتی نتوانستم در شهر یا نیروی دلخواه به سربازی بروم. در نتیجه دو سال از وقت با ارزشم را در تبریز و کوه‌های لرستان سپری کردم. طی این مدت تنها ارتباطم با کامپیوتر مجموعه Microsoft Office و خواندن یک کتاب ASP بود.

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

۷- دیگر موارد متفرقه مثل عدم کار روی پروژه‌های کد باز معروف، عدم حضور جدی و موثر در المپیادها، مسابقات و همایش‌های دانشجویی، دوست‌یابی نادرست و…

تجاربی از اسکرام

همان طور که می‌دانید اسکرام یکی از متودولوژی‌های جدید توسعه نرم‌افزار از خانواده Agile است. این روش مزایای زیادی، اقلاً برای ما، دارد و روز به روز رواج بیشتری در دنیا پیدا می‌کند. ما هم در مدت اخیر تصمیم گرفتیم از این روش برای یکی دو تا از پروژه‌های جدید استفاده کرده و مزایا و معایبش را به طور عملی لمس کنیم. یکی از این پروژه‌ها، پروژه‌ی کوچکی با ASP.NET بود که تعداد افراد درگیر با آن چه در نقش برنامه‌نویس چه در نقش Product Owner کمتر از ۵ نفر بوده و انجام فاز اول آن چیزی حدود ۱۰ هفته طول کشید. انجام این پروژه با اسکرام برای من که اسکرام را با کتاب Scrum and XP from the Trenches یاد گرفته بودم نکات و تجاربی را با خود به همراه داشت که ذیلاً می‌آیند:

۱- قوانین اسکرام برای غربی‌های منظم نوشته شده نه کشورهایی مثل ما. در نتیجه نمی‌توان از مثلاً افرادی مثل Product Owner انتظار داشت همیشه فهرست PBIهایش را به طور کامل و منظم به همراه داشته باشد.

۲- Self Organized بود تیم در اسکرام خیلی مورد توجه قرار گرفته ولی عموماً ایرانی‌ها عادت دارند یک نفر همیشه کارهایشان را به آنها یادآوری کرده و یک نفر دیگر انجام آن کارها را مدام چک کند. ضعف این خصیصه در افراد برنامه‌نویس خیلی از کیفیت کار در اسکرام کم می‌کند.

۳- روی برنامه و اصول پیش رفتن در نظر خیلی افراد یک کار لوکس (قرتی‌بازی) به نظر می‌رسد. مثلاً شکستن یک PBI به چند Task و یادداشت آن در Task Board یکی از آن کارهاست.

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

۵- ایرانی‌ها به طور کلی عاشق Customize کردن هستند. مثلاً دوست دارند موتور پیکان را روی بدنه پژو بگذارند و به اسم پژو آر-دی به بازارا بفرستند. یا این که مدام در فکر بومی‌سازی علوم و فناوری خارجی بپردازند. متاسفانه اسکرام هم از این قاعده سرطانی مستثنی نیست و افراد عاشق دستکاری قوانین آن هستند. مثلا در اسکرام گفته شده طول اسپرینت‌ها باید یکسان باشد ولی ما هم اسپرینت‌های یک هفته‌ای داشتیم و هم اسپرینت‌های دو هفته‌ای.

۶- …

توجه: اگر کسی از همکاران شرکتی بنده این متن را می‌خواند یا کسانی این متن را می‌خوانند که فکر می‌کنند در تیم آنها چنین مشکلاتی به وجود نخواهد آمد متوجه باشند که بیشتر این مشکلات از نحوه کار تیمی ما ایرانی‌ها و خصوصیات اجتماعی/فرهنگی ما سرچشمه می‌گیرد و چندان ربطی به این شرکت و آن شرکت ندارد.

‫آیا ORM برای ما مناسب است؟

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

در دنیای Object Oriented Programming کار مستقیم با دیتابیس یک معضل حساب می‌شود. چون به خاطر ماهیت رابطه‌ای بودن آنها نمی‌شود با آنها مثل object برخورد کرد. به همین خاطر ORMها به وجود آمدند تا دیتابیس را زیر خودشان مخفی کرده و آن را به شیوه‌ی مناسب object oriented به لایه‌های بالاتر تحویل دهند.

برای استفاده کامل از امکانات ORM باید همه اصول Object Oriented Programming رعایت شود. یعنی تعریف کلاس‌ها، اینترفیس‌ها و روابط بین آنها باید مطابق اصول باشد. مثلاً اگر عادت به استفاده از متغیرهای عمومی دارید، اگر متودها را فقط به صورت استاتیک می‌نویسید، اگر متودهایی می‌نویسید که گاه به ۵۰۰ خط هم می‌رسند، اگر عادت به استفاده از مفاهیم سه‌گانه OOP ندارید، اگر نمی‌دانید Design Pattern چیست و… باید روش خود را تغییر دهید در غیر این صورت استفاده از ORM نه تنها هیچ مزیتی برای شما ندارد بلکه شما را حسابی هم به دردسر خواهد انداخت.

در بحث Documentation در ORM و دیتابیس، مهم‌ترین موضوعی که با آن برخورد می‌کنید این است که دیگر اجازه استفاده از ERD ندارید. بلکه به جای آن باید از UML Class Diagram استفاده کنید. چون ERD بر اساس ماهیت رابطه‌ای است ولی Class Diagram بر اساس ماهیت Object Oriented ساخته شده. اگر افراد گروه شما به ERD عادت دارند و نمی‌توانند یا نمی‌خواهند از Class Diagram استفاده کنند، این یعنی یک زنگ خطر. چون این افراد بعدها مشکلات زیادی را به وجود خواهند آورد.

تعامل با دیتابیس یکی از بنیادی‌ترین تغییراتی است که استفاده از ORM ایجاد می‌کند. ORMها این تفکر را تبلیغ می‌کنند که عملیات داده‌ای در سمت کد اتفاق بیفتند نه در داخل دیتابیس. این یعنی حداقل استفاده از امکانات داخلی دیتابیس. به عبارت دیگر اگر می‌خواهید از ORM استفاده کرده و از همه مزایای بهره‌مند شوید باید استفاده از Stored Procedureها، Viewها، Triggerها و… را بی‌خیال شوید. حال اگر در شرکتی هستید که همه Business برنامه را از طریق Stored Procedureها، Triggerها، Viewها و… اعمال می‌کنند، بدانید که استفاده از ORM در آنجا خیلی سخت بوده و مخالفان سرسخت زیادی خواهد داشت.

تجربه‌ای که ما در شرکت قبلی داشتیم در بعضی جاها با خودش شکست به همراه داشت. البته میزان موفقیت در استفاده از ORM از نظر شخص خودم حداقل ۷۵ درصد بود. متاسفانه علت آن بخش‌های ناموفق فقر دانش خودمان در استفاده از ORM بود. مهم‌ترین آن‌ها عبارتند از:

۱- چون نتوانسته بودیم ORM خودمان را به خوبی Config کنیم دچار مشکل Performance شده و مجبور شده بودیم بعضی جاها استثنا قائل شده و از Store Procedure استفاده کنیم.

۲- در صفحات ASP.NET برای Data Binding از ObjectDataSource استفاده نکرده بودیم در نتیجه مجبور شده بودیم بیشتر کارها از جمله Paging و… را از طریق code behind انجام دهیم. این موضوع باعث حجیم شدن و پیچیده شدن بیهوده‌ی code behind شده بود. علت عدم استفاده از ObjectDataSource نا آگاهی خودمان بود ولی به هر صورت اگر از به جای ORM از ADO.NET استفاده می‌کردیم کمتر دچار این مشکلات می‌شدیم.

۳- ما برای گزارش‌گیری از MS SQL Server Reporting Services استفاده می‌کردیم. گزارشات در این سیستم به دو نوع client و server تقسیم می‌شوند. ما بلد نبودیم یا شاید هم راهی وجود نداشت که خروجی‌های objectی مثل IList را به گزارشات سروری بفرستیم. در نتیجه آنجا هم مجبور شدیم برای تهیه گزارشات به صورت مستقیم از Sql استفاده کنیم.

توصیه شخصی من برای استفاده یا عدم استفاده از ORM این است که با توجه به پیشرفت فناوری‌ها و گرایشات روز دنیای نرم‌افزار و با توجه به رواج روز افزون روش‌های Agile و TDD بهتر است شما هم هر چه زودتر خودتان را به جمع کاربران ORM اضافه کنید. درست است که ORM درصد خیلی کمی از سرعت برنامه را کاهش می‌دهد، تغییرات زیادی را در روش کار می‌دهد و نیاز زیادی به آموزش و مطالعه دارد، اما در مجموع هزینه‌های تولید را کاهش می‌دهد، نگهداری کد را راحت‌تر می‌کند، تعداد باگ‌ها را کاهش می‌دهد و در نهایت هم منافع کارفرما و مدیریت را با خود به همراه دارد و هم رضایت برنامه‌نویسان را.

Continuous Integration with TFS

It’s a few months that I am dealing with continuous integration, automatic builds, TFS and Team Foundation Build deeply. Experiences during this period learned me some points that I’m glad to share with all:

1. Don’t assume anything about build agent. Specifically don’t assume any library is installed on the agent, any assembly registered in build agent’s GAC, any specific file/folder structure exists in build agent, etc. Otherwise you may encounter build breaks in other agents or at another time. Best practices here is to assume that build agent has just .Net framework installed on it and nothing more.

2. Always add assembly references from source control maintained dlls in same project and just as relative path not as absolute path. Otherwise you may encounter build breaks.

3. Never ever let anyone direct access to live machine that is dedicated to install continuous integration results instantly, specifically for web application projects. Because someone may manually add/modify a file/folder in the web application path. So you may end with a software that needs manual modifications that are never documented nor automated.

4. Automate database creation. Either via maintaining database creation scripts in source control or with help of ORM’s database auto generating feature.