ساختن متدهاي كمكي Razor در ASP.NET MVC

در نسخه 3 ي  ASP.NET MVC موتور نمايش(view-engine) جديدي بنام Razor اضافه شده ميزان كد نويسي View ها رو كم كرده.
يكي از قابليت هاي جالب اون ساختن متدهاي كمكي به صورت اعلانيه(Declarative) كه اين امكان رو ميده در همون فايل View مون بتونيم متدهاي كمكي بسازيم كه ازش در سرتاسر اون View استفاده كنيم.
براي مثال فرض كنيد جدولي داريم كه ستوني بنام قيمت(Price) داره حالا ميخواهيم اگه اون ستون كمتر از يك عددي بود اون ستون قرمز بشه و…
براي نوشتن اين مثال از سري آموزشي MVC Music Store استفاده ميكنم.براي همين قسمت Model و Controllers رو نمينويسم.
براي نوشتن متد كمكي از Helper@ استفاده ميكنم و بقيه مراحل دقيقا مثل نوشتن يك متد عاديه البته تنها فرقش با متد اينه كه بدنه ي متد فقط شامل كدهاي C#‎ نيست.

@helper PriceHighlighter(decimal inputPrice, decimal treshold)
    {
        if (inputPrice > treshold)
        {
            <span style="background-color: red">@inputPrice</span>  
        }
        else
        {
            @inputPrice
        }
}

همنطور كه گفتم فرق خاصي با متدهاي عادي نداره.ورودي رو با مقدار مورد نظرمون مقايسه ميكنيم و اگه بيشتر از اون بود يك تگ SPAN با رنگ قرمز و وروديمون برمي گردونيم(من زياد HTML م خوب نيست اگه بجز SPAN تگ ديگه ي ميشه استفاده كرد بگيد).

</td>
	@PriceHighlight(item.Price, 9)
</td>

نحوه استفاده هم مثل فراخواني يك متد عاديه.

تا اينجا بسيار خوب ولي  چندتا مشكل

  • با زياد شدن تعداد متد ها View ي ما پر ميشه از اين متدها كه خوب نيست
  • امكان استفاده از اين متدها محدود به همون View ي هست كه متد داخلش نوشته شده

براي رفع اين مشكل ها بايد تعريف كدهاي كمكيمون رو تو سطح برنامه بنويسم به نوعي Scope كدها رو بيشتر كنيم تا در تمام View ها قابل استفاده باشه.
براي اينكار كافيه يك فولدر بنام App_Code داخل پروژه ايجاد كنيم و داخل اون يك MVC 3 View Page (Razor)‌‎ (يا هر آيتمي با پسوند CSHTML) اضافه كنيم(هرچي داخلش هست رو پاك كنيد) و متدهاي كمكي مورد نظرمون رو داخل اون اضافه كنيم.

نحوه استفاده هم مثل فراخواني متدهاي استاتيك يك كلاس ميمونه مثلا RazorHelpers.PriceHighlighter و…

نكته:با استفاده از اين روش نميتونيم از متدهاي كمكي خود MVC كه از طريق Html به اونا دسترسي داريم استفاده كنيم.البته براي رفع اين مشكل روشي اينجا معرفي شده كه ميتونيد استفاده كنيد.

نکات شرینک کردن فایل های دیتابیس در SQL Server

با ايده گرفتن از Arik Poznanski نتيجه گيريم رو از شرينك كردن فايل هاي ديتابيس اول مينويسم

«شرينك كردن در صورت نياز»

ما دو نوع شرينك كردن داريم

  • شرينك كردن ديتا فايل (خيلي بد)
  • شرينك كردن لاگ فايل (بد)

يه سري مفاهيم اوليه در شرينك هست كه در هر دو نوع شرينك ثابته اول اين مفاهيم رو مرور كنيم.
وقتي فايل هاي ديتابيس ميخوان بزرگ بشن بر اساس Autogrowth ي كه ست كرديد اون مقدار مورد نظر براي اطمينان از نداشتن بد سكتور بايد zero byte فرمت بشه حال فرض كنيد رشد بانك به صورت درصدي باشه (كه به صورت پيشفرض هست) و ديتابيس شما گيگا بايتي باشه چه حجم زيادي بايد zero byte فرمت بشه و اين يعني افت Performance. البته خبر خوب اينه كه عمل بزرگ شدن فايل از SQL Server 2005 به بعد فقط براي ديتا فايل با zero byte فرمت انجام نميشه (Instant File Initialization).همه اينا رو گفتم تا برسم به اينجا كه بزرگ شدن فايل يه عمليات زمانبريه پس اگه شما از نظر حجم Storage مشكلي نداريد تا جاي كه امكان داره فايلهاي ديتابيستون رو شرينك نكنيد.

چرا شرينك كردن ديتا فايل خيلي بده!
وقتي شما ديتا فايلتون رو شرينك ميكنيد SQL مياد Extent (واحدي هست براي مديريت فضا شامل هشت Page پشت سر هم) هاي آخر فايل رو بدون توجه به ترتيب منطقي Page ها و Index ها تو قسمت هاي خالي اول فايل ميزاره و اين يعني تك تكه شدن (Fragmentation) ايندكس هاي شما (البته Clusterd ها) بنابراين كلا بيخيال اين نوع شرينك بشيد…
نکته:شرینک کردن با سویچ TRUNCATEONLY این جابجائی Extend ها رو نداره
همونطور كه ميدونيد شرينك كردن يكي از Task هاي موجود در Maintenance Plan هستش و بقول استادم

SQL Server ي كه Maintenance Plan نداشته باشه معلومه DBA بالاسرش نيست

پس تقريبا همه سرور ها Maintenance Plan رو دارن چندتا نكته

  • شرينك كردن رو تا حد ممكن اتومات نكنيد
  • با انجام Rebuild Index و بعد Shrink فقط و فقط وقت و منابع وكارايي و… سرور رو هدر كردين.دلیلش چيه؟

چرا شرينك كردن لاگ فايل بده؟
وقتی شما لاگ فایلتون (Transactional Log File) رو شرینک میکنید همونطور که قبلا گفتم با توجه به اینکه لاگ فایل باید zero byte فرمت بشه موقع بزرگ شدن فایل بسته به میزان Autogrowth انتخابی سیستم شما افت Performance داره.البته از بین دو نوع شرینکی که گفتم انجام این نوع شرینک منطقی هست که البته بیشتر افراد برای «پراندن لاگ» میان لاگ فایل رو شرینک میکنن پس اگه شما مشکل حجم Storage ندارید میتونید این نوع شرینک رو هم انجام ندید توجه کنید تمام این پیشنهاد های که داده میشه با توجه به اینه که مدل Recovery شما رو FULL ست شده.

یک نکته مهم «Truncate شدن لاگ اندازه فیزیکی اونو کم نمیکنه»

همنطور که میدونید اگه مدل Recovery شما FULL باشه بعد از لاگ بکاپ گرفتن لاگ فایل شما Truncate میشه ولی نکته مهم اینه Truncate شدن لاگ اندازه فیزیکی اونو کم نمیکنه بلکه اون قسمت رو مجددا قابل نوشتن میکنه.همنطور که گفتم انجام این نوع شرینک منطقی هست. کی و کجا؟
فرض کنید شما تو سرور ساعت 5 صبح Maintenance Plan تعریف کردید و همیشه میبنید که لاگ بکاپ ساعت 7 صبح شما خیلی بزرگه مشکل کجاس؟
تمام عملیات Maintenance Plan تو لاگ نوشته میشه(والبته تمام عملیات SQL Server به صورت write-ahead) و این باعث میشه لاگ فایل شما بزرگ بشه و چون حتی پس از لاگ بکاپ گرفتن این فضا کم نمیشه ازاینرو یکی از جاهای که میشه لاگ رو شرینک کرد(پراند) اینجاس.البته برای کم کردن اندازه لاگ بکاپ ساعت 7 فکر میکردم تغییر مدل Recovery به BULK_LOGGED جواب بده ولی نوچ!(باید بشتر مطالعه کنم)

در آخر شما Auto_Shrink رو تو SQL Server فعال میکیند؟