اشتراکها
نکاتی در مورد کلاس CultureInfo
- برنامههای وب نیازی به نصب بر روی تک تک کلاینتها و همچنین به روز رسانی مداوم کلاینتها را ندارند. به این صورت مدیریت چند صد کاربر در یک سازمان سادهتر از قبل خواهد بود. دیگر نگران این نخواهید بود که آیا فلان کاربر آخرین به روز رسانیها را نصب کرده (دریافت کرده) یا خیر.
- امکان دسترسی از راه دور، برای مثال از طریق اینترنت یا VPN یا RRAS و خطوط دایال آپ (برای مثال دسترسی سادهتر دفاتر مختلف یک سازمان به اطلاعات یکدیگر یا امکان داشتن کارکنانی که از راه دور برای شما کار میکنند).
- امکان ذخیره سازی دادهها در سازمانی دیگر (هاست کردن این برنامهها در محیطهای ابری(!) (cloud computing) هزینههای تهیه و نگهداری سخت افزارهای یک سازمان را نیز کاهش میدهند).
- کاهش هزینههای سازمان با توجه به اینکه اگر از سرورهای قدرتمندی استفاده شود؛ از یک برنامهی وب چندین هزار یا چند میلیون کاربر میتوانند استفاده کنند بدون اینکه نگران تامین هزینه مجوز استفاده از برنامهی تهیه شده به ازای هر کاربر باشید.
- امکان دسترسی به برنامهی وب تهیه شده در انواع و اقسام سیستم عاملهایی که تنها مجهز به یک مرورگر وب هستند (نتیجه نهایی قابل استفاده مستقل از سکو است). برای مثال این روزها به کمک Adobe AIR ، Silverlight و یا کتابخانههای اسکریپتی مانند jQuery و ASP.Net Ajax، بسیاری از تواناییهای نمایشی برنامههای دسکتاپ را در وب نیز میتوان شاهد بود با این خصوصیت که نتیجهی نهایی مستقل از سکو است.
- در این حالت کلاینتها نیازی به داشتن سخت افزارهای قوی ندارند (که در کاهش هزینههای یک سازمان مؤثر است). همچنین این برنامهها مشکلات ناسازگاری با سخت افزارها و نگارشهای مختلف سیستم عاملها را نیز ندارند. بنابراین یک سازمان میتواند بودجهی خود را صرف تهیهی سرورهای بهتری کند.
- کلاینتها با توجه به محدود بودن دسترسیهای امنیتی اعمالی توسط مرورگرها، امنیت بیشتری خواهند داشت. به همین ترتیب کاربران برای استفاده از این برنامهها نیز نیازی به دسترسی بالا در یک سازمان برای اجرای مرورگر خود نخواهند داشت (کمتر جملهی "من دسترسی ادمین میخواهم" را خواهید شنید).
- امکان مونیتور کردن سادهتر فعالیت کاربران در برنامه.
- در صورت محافظت از سرور، کدهای شما از خطر دزدیده شدن مصون(تر) هستند.
- مدیریت سادهتر و مجتمع اطلاعات تولیدی با توجه به اینکه همه چیز باید بر روی سرور ذخیره شود. به این صورت مدیریت نقل مکان کاربران از یک کامپیوتر به کامپیوتری دیگر نیز سادهتر می شود؛ زیرا چیزی را قرار نیست جابجا کنند (نه اطلاعات و نه برنامه را). اگر یکی از کامپیوترهای کلاینتها قابل استفاده نباشد، به سادگی میتواند از کامپیوتری دیگر در شبکه استفاده کند، بدون اینکه معطل تیم فنی شود تا برنامهای را برای او نصب و راه اندازی کنند. به علاوه تهیه پشتیبان از اطلاعات سرورها نیز همیشه سادهتر است از تهیه پشتیبان از 100 ها کامپیوتر موجود در شبکه.
- اگر خروجی برنامهی وب شما تنها از صفحات وب و جاوا اسکریپت تشکیل شده باشد، امکان دسترسی آن در دستگاههای موبایل به سادگی میسر است.
C# 7 is a major update with a lot of interesting new capabilities. And while there are plenty of articles on what you can do with it, there aren't quite as many on what you should do with it. Using the principles found in the .NET Framework Design Guidelines, we're going to take a first pass at laying down strategies for getting the most from these new features.
در 5 سال آینده مواردی که در ادمه برشمرده خواهند شد، نقش بسیار مهمی را در دنیای برنامه نویسی و جهت گیریهای آن ایفا خواهند کرد (برای مثال اگر برای شما این سؤال مطرح است که هدف از WCF ، REST services ، سیلورلایت 3 و غیره چیست، این مقالهی کوتاه را مطالعه نمائید) :
الف) Object Relational Mapping
ORM یکی از بازیگرهای واضح خواهد بود. خصوصا پروژهای مانند Fluent NHibernate با ویژگیهای زیر:
- سابقهای 10 ساله (قسمت عمدهای از این سابقه به دنیای جاوا بر میگردد)
- امکان استفاده از انواع و اقسام دیتابیسها توسط آن
- پشتیبانی از Linq
- و ...
ب) نرم افزار به عنوان سرویس ( Software as a Service یا SaaS )
نرم افزار به عنوان سرویس یک مفهوم تجاری است که در آن مصرف کننده بر اساس نیازهایش هزینهی یک نرم افزار را خواهد پرداخت. بر این اساس برنامه نویسی در زمینههای طراحی و مدیریت دست خوش تغییرات عمدهای میشود. شاید نیازی به ذکر نباشد که حتی مایکروسافت نیز در حال برنامه ریزی برای این نوع از توسعه است.
پرداختن به SaaS نیازمند یک سری از ویژگیها است:
- سادگی توسعه و دستیابی: در این مدل تجاری، استفاده و دسترسی به نرم افزار مورد نظر باید بسیار ساده باشد. بر این اساس برنامههای تحت وب، یا برنامههای هاست شده توسط مرورگرها (مانند سیلورلایت) محبوبیت بیش از پیشی را خواهند یافت.
- قابلیت تنظیم و ماژولار بودن برنامهها: در این مدل نیاز است تا کاربر تنها هزینهی ماژولهایی را بپردازد که به آنها نیاز دارد و این امر سبب بازنگری در طراحی و توسعهی برنامههای موجود خواهد شد.
- نیاز به زیر ساخت بهینه و سریعی خواهد بود: از آنجائیکه کاربران بسیار ساده میتوانند از یک برنامه به برنامه و شرکتی دیگر رجوع کنند، برای بقا باید جنگید! نیاز به زیر ساختهایی وجود خواهد داشت که توسط آنها بتوان نیازهای کاربران را در حداقل زمان ممکن برآورده کرد و این موارد نیاز به آموختن یکی از فریم ورکهای مطرح موجود را خواهد داشت به همراه آموختن مباحث مدیریت پروژه، آشنایی با آزمونهای واحد، کنترل کیفیت ، یکپارچگی مداوم و امثال آن.
ج) پردازش ابری
پردازش ابری شبیه به آنچیزی که مایکروسافت Azure ارائه میدهد، نیز یکی از نتایج مفهوم تجاری SaaS است. تمرکز پردازش ابری بر روی ارائهی وب سرورها، مکانهای ذخیره داده و امثال آن است. به این صورت شما دیگر درگیر تهیه و پرداخت هزینه جهت راه اندازی دیتاسنتر ویژهی خود نخواهید شد و بسیاری از هزینههای شما کاهش خواهند یافت. بهره برداری تجاری گسترده از این روش با توجه به توسعهی فریم ورکهای ویژهی این نوع پردازشها، آموزش و غیره ، بین سالهای 2010 و 2015 شروع خواهد شد.
د) اجرای موازی
پردازش ابری اثرات خاص خودش را بر روی دنیای نرم افزار و برنامه نویسی خواهد گذاشت. این طبیعت توزیع شده سبب خواهد شد که در آینده از برنامه نویسیهای چند ریسمانی و مسایل همزمانی حاصل از آنها بیشتر بشنوید و نهایتا معماری برنامهها به سمت استفاده از روشهای زیر سوق خواهند یافت:
REST services;
Message-based distributed architectures, i.e.: see NServiceBus, Mass Transit or Rhino Service Bus
Message-based distributed architectures, i.e.: see NServiceBus, Mass Transit or Rhino Service Bus
ه) برنامههای غنی وب یا Rich Internet Applications
Rich Internet Applications یا RIA نقش مهمی را در SaaS بازی خواهند کرد و هدفگیری مایکروسافت در این باره ارائه Silverlight 3.0 و Microsoft .NET RIA Services است. هر چند این موارد راه طولانی (یکی دو ساله) را در پیش خواهند داشت تا به حد استانداردهای لازم برسند اما حرکتهای مهمی در این زمینه به شمار میروند.
برداشتی آزاد از Development in 5 Years Would be Affected by
تصادف برای یک راننده حتی در صورت داشتن بیمه نامهای معتبر، گران تمام خواهد شد (از لحاظ جانی/مادی/...). بنابراین صرف نظر از اینکه شرکت بیمه کننده چه میزان از خسارت راننده را جبران خواهد کرد، باید تا حد ممکن از تصادفات بر حذر بود (defensive driving).
در برنامه نویسی، استثناءها (Exceptions) مانند تصادفات هستند و مدیریت استثناءها (exception handling)، همانند بیمه خودرو میباشند. هر چند مدیریت استثناءها جهت بازگردان برنامه شما به ادامه مسیر مهم هستند، اما جایگزین خوبی برای Defensive programming به شمار نمیروند. استثناءها و مدیریت آنها برای برنامه گران تمام میشوند (خصوصا از لحاظ میزان مصرف منابع سیستمی و سربارهای مربوطه). بنابراین در برنامه باید توجه خاصی را به این موضوع معطوف داشت که چه زمانی، چگونه و در کجا ممکن است استثنائی رخ دهد و علاج واقعه را پیش از وقوع آن نمود.
اصل اول Defensive programming : همیشه ورودی دریافتی را تعیین اعتبار کنید
به مثال زیر دقت بفرمائید:
public void LogEntry(string msg)
{
string path = GetPathToLog();
using (StreamWriter writer = File.AppendText(path))
{
writer.WriteLine(DateTime.Now.ToString(CultureInfo.InstalledUICulture));
writer.WriteLine("Entry: {0}", msg);
writer.WriteLine("--------------------");
}
}
قرار هست رخدادهای برنامه را توسط این متد، لاگ کنیم. اکنون لحظهای دقت نمائید که این تابع در چه مواقعی ممکن است دچار مشکل شود:
path میتواند یک رشته خالی باشد.
path میتواند نال باشد.
path میتواند حاوی کاراکترهای غیرمجازی باشد.
path میتواند فرمت نادرستی داشته باشد.
path میتواند به محلی ناصحیح اشاره نماید.
path میتواند اصلا وجود نداشته باشد.
فایل مورد نظر ممکن است readonly باشد.
برنامه ممکن است دسترسی لازم را برای نوشتن در مسیر ذکر شده، نداشته باشد.
فایل مورد نظر ممکن است توسط پروسهای دیگر قفل شده باشد.
ممکن است در لحظه نوشتن یا خواندن بر روی فایل، هارد دیسک دچار مشکل گردد.
و ...
رخ دادن هر کدام از موارد ذکر شد منجر به بروز یک استثناء خواهد شد.
چگونه این وضعیت را بهبود بخشیم؟
فرض کنید متد GetPathToLog قرار است مسیر ذخیره سازی لاگها را از کاربر در یک برنامه ASP.Net دریافت کند. برای این منظور باید حداقل دو مورد را منظور کرد.
<asp:TextBox ID="txtPath" runat="server" MaxLength="248" />
<asp:RequiredFieldValidator ID="reqval_txtPath" runat="server" ControlToValidate="txtPath" ErrorMessage="Path is required." />
<asp:RegularExpressionValidator ID="regex_txtPath" runat="server" ControlToValidate="txtPath" ErrorMessage="Path is invalid." ValidationExpression='^([a-zA-Z]\:)(\\{1}|((\\{1})[^\\]([^/:*?<>”|]*(?<![ ])))+)$' />
برای تکست باکس ارائه شده، ابتدا یک RequiredFieldValidator در نظر گرفته شده تا مطمئن شویم که کاربر حتما مقداری را وارد خواهد کرد. اما این کافی نیست. سپس با استفاده از عبارات باقاعده و RegularExpressionValidator بررسی خواهیم کرد که آیا فرمت ورودی صحیح است یا خیر.
تا اینجا 4 مورد اول مشکلاتی که ممکن است رخ دهند (موارد ذکر شده فوق)، کنترل میشوند بدون اینکه احتمال رخ دادن این استثناءها در برنامه وجود داشته باشد. Defensive programming به این معنا است که طراحی برنامه باید به گونهای باشد که در اثر استفادهی غیر قابل پیش بینی از آن، در عملکرد برنامه اختلالی رخ ندهد.
چرا باید از ابزارهای Object relational Mapper یا به اختصار ORM استفاده کرد؟ در اینجا سخن در مورد ORM خاصی نیست. هدف تبلیغ یک محصول ویژه هم نمیباشد و یک بحث کلی مد نظر است.
کار ابزارهای ORM خواندن ساختار دیتابیس شما بوده و سپس ایجاد کلاسهایی بر اساس این ساختار ، برقراری ارتباط بین اشیاء ایجاد شده و جداول، ویووها، رویههای ذخیره شده و غیره میباشد. همچنین این ابزارها امکان تعریف روابط one-to-one, one-to-many, many-to-one, و many-to-many بین اشیاء را نیز بر اساس ساختار دیتابیس شما فراهم میکنند.
در ادامه به فواید استفاده از ORM ها خواهیم پرداخت:
الف) یک ابزار ORM زمان تحویل پروژه را کاهش میدهد
اولین و مهمترین دلیلی که بر اساس آن در یک پروژه، استفاده از ORM حائز اهمیت میشود، بحث بالا بردن سرعت برنامه نویسی و کاهش زمان تحویل پروژه به مشتری است. این کاهش زمان بسته به نوع پروژه بین 20 تا 50 درصد میتواند خود را بروز دهد.
بدیهی است ابزارهای ORM کار شگفت انگیزی را قرار نیست انجام دهند و شما میتوانید تمام آن عملیات را دستی هم به پایان رسانید؛ اما اجازه دهید یک مثال کوتاه را با هم مرور کنیم.
برای پیاده سازی یک برنامه متداول با حدود 15 تا 20 جدول، حدودا به 30 شیء برای مدل سازی سیستم نیاز خواهد بود و برنامه نویسی این مجموعه بین 5000 تا 10000 سطر کد را به خود اختصاص خواهد داد. بدیهی است برنامه نویسی و آزمایش این سیستم چندین هفته یا ماه به طول خواهد انجامید.
اما با استفاده از یک ORM ، عمده وقت شما به طراحی سیستم و ایجاد ارتباطات بین اشیاء و دیتابیس در طی یک تا دو روز صرف خواهد شد. ایجاد کد بر اساس این مجموعه و با کمک ابزارهای ORM ، آنی است و با چند کلیک صورت میگیرد.
ب) یک ابزار ORM کدی با طراحی بهتر را تولید میکند
ممکن است شما بگوئید که کد نویسی من بینظیر است و از من بهتر کسی را نمیتوانید پیدا کنید! به تمامی زوایای کار خود مسلطم و نیازی هم به اینگونه ابزارها ندارم!
عدهای از شما به طور قطع اینگونهاید؛ اما نه همه. در یک تیم متوسط، همه نوع برنامه نویس با سطوح مختلفی را میتوانید پیدا کنید و تمامی آنها برنامه نویسها و یا طراحهای آنچنان قابلی هم نیستند. بنابراین امکان رسیدن به کدهایی که مطابق اصول دقیق برنامه نویسی شیء گرا نیستند و در آنها الگوهای طراحی به خوبی رعایت نشده، بسیار محتمل است. همچنین در یک تیم زمانیکه از یک الگوی یکسان پیروی نمیشود، نتایج نهایی بسیار ناهماهنگ خواهند بود.
در مقابل استفاده از ORM های طراحی شده توسط برنامه نویسهای قابل (senior (architect level) engineers) ، کدهایی را بر اساس الگوهای استاندارد و پذیرفته شدهی شیءگرا تولید میکنند و همواره یک روند کاری مشخص و هماهنگ را در یک مجموعه به ارمغان خواهند آورد.
ج) نیازی نیست تا حتما یک متخصص دات نت فریم ورک باشید تا از یک ORM استفاده کنید
قسمت دسترسی به دادهها یکی از اجزای کلیدی کارآیی برنامه شما است. اگر طراحی و پیاده سازی آن ضعیف باشد، کل برنامه را زیر سؤال خواهد برد. برای طراحی و پیاده سازی دستی این قسمت از کار باید به قسمتهای بسیاری از مجموعهی دات نت فریم ورک مسلط بود. اما هنگام استفاده از یک ORM مهمترین موردی را که باید به آن تمرکز نمائید بحث طراحی منطقی کار است و ایجاد روابط بین اشیاء و دیتابیس و امثال آن. مابقی موارد توسط ORM انجام خواهد شد و همچنین میتوان مطمئن بود که پیاده سازی خودکار انجام شده این قسمتها، بر اساس الگوهای طراحی شیءگرا است.
د) هنگام استفاده از یک ابزار ORM ، مدت زمان آزمایش برنامه نیز کاهش مییابد
بدیهی است اگر قسمت دسترسی به دادهها را خودتان طراحی و پیاده سازی کرده باشید، زمان قابل توجهی را نیز باید به بررسی و آزمایش صحت عملکرد آن بپردازید و الزامی هم ندارد که این پیاده سازی مطابق بهترین تجربیات کاری موجود بوده باشد. اما هنگام استفاده از کدهای تولید شده توسط یک ابزار ORM میتوان مطمئن بود که کدهای تولیدی آن که بر اساس یک سری الگوی ویژه تولید میشوند، کاملا آزمایش شده هستند و همچنین صدها و یا هزارها نفر در دنیا هم اکنون دارند از این پایه در پروژههای موفق خود استفاده میکنند و همچنین بازخوردهای خود را نیز به تیم برنامه نویسی آن ابزار ORM ارائه میدهند و این مجموعه مرتبا در حال بهبود و به روز شدن است.
ه) استفاده از یک ابزار ORM ، کار برنامه نویسی شما را سادهتر میکند
توضیح این قسمت نیاز به ذکر یک مثال دارد. لطفا به مثال زیر دقت بفرمائید:
try {
Employees objInfo = new Employees();
EmployeesFactory objFactory = new EmployeesFactory();
objInfo.EmployeeID = EmployeeID;
objFactory.Load(objInfo);
// code here to use the "objInfo" object
}
catch(Exception ex) {
// code here to handle the exception
}
به نظر شما کار کردن با یک یا چند شیء تولید شده که نمایانگر ساختار دیتابیس شما هستند و با استفاده از اینترفیس عمومی آنها میتوان تمامی اعمال بارگذاری، درج و حذف و غیره را انجام داد، سادهتر است یا کار کردن با کوهی از دستورات ADO.Net ؟
برداشتی آزاد از Five Reasons for using an ORM Tool
اگر به میزان مصرف حافظه اولیهی برنامههای دات نت دقت کنیم، نسبت به مثلا یک برنامهی MFC چند برابر به نظر میرسند و ... این علت دارد:
زمانیکه یک برنامهی مبتنی بر دات نت اجرا میشود، ابتدا JIT compiler شروع به کار کرده و شروع به کامپایل برنامه میکند. این بارگزاری هم در همان پروسهی اصلی برنامه انجام میشود. به همین جهت میزان مصرف حافظهی برنامههای دات نت عموما بالا به نظر میرسد.
اکنون سؤال اینجا است که آیا می توان این حافظهای را که دیگر مورد استفاده نیست (و توسط JIT compiler اخذ شده) به سیستم بازگرداند و محاسبهی مجددی را در این مورد انجام داد. پاسخ به این سؤال را در متد ReEvaluateWorkingSet زیر میتوان مشاهده کرد:
using System;
using System.Diagnostics;
namespace Toolkit
{
public static class Memory
{
public static void ReEvaluateWorkingSet()
{
try
{
Process loProcess = Process.GetCurrentProcess();
//it doesn't matter what you set maxWorkingSet to
//setting it to any value apparently causes the working set to be re-evaluated and excess discarded
loProcess.MaxWorkingSet = (IntPtr)((int)loProcess.MaxWorkingSet + 1);
}
catch
{
//The above code requires Admin privileges.
//So it's important to trap exceptions in case you're running without admin rights.
}
}
}
}
در این متد ابتدا پروسه جاری دریافت شده و سپس MaxWorkingSet به یک عدد دلخواه تنظیم میشود. مهم نیست که این عدد چه چیزی باشد، زیرا این تنظیم سبب میشود که در پشت صحنه به شکل حساب شدهای حافظهای که مورد استفاده نیست به سیستم بازگردانده شود و سپس عددی که در task manager نمایش داده میشود، مجددا محاسبه گردد. همچنین باید دقت داشت که این کد تنها با دسترسی مدیریتی قابل اجرا است و به همین دلیل وجود این try/catch ضروری است.
نحوه استفاده از متد ReEvaluateWorkingSet در برنامههای WinForms :
فایل Program.cs را یافته و سپس در روال رویداد گردان Idle برنامه، متد ReEvaluateWorkingSet را فراخوانی کنید (مثلا هر زمان که برنامه minimized شد اجرا میشود):
//Program.cs
namespace MemUsage
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
//...
Application.Idle += applicationIdle;
}
static void applicationIdle(object sender, EventArgs e)
{
Memory.ReEvaluateWorkingSet();
}
}
}
نحوه استفاده از متد ReEvaluateWorkingSet در برنامههای WPF :
فایل App.xaml.cs را یافته و سپس در روال رویدادگردان Deactivated برنامه، متد ReEvaluateWorkingSet را فراخوانی کنید:
//App.xaml.cs
public App()
{
this.Deactivated += appDeactivated;
}
void appDeactivated(object sender, EventArgs e)
{
Memory.ReEvaluateWorkingSet();
}
تاثیر آن هم قابل ملاحظه است (حداقل از لحاظ روانی!). تست کنید!
اشتراکها
طراحی برای حافظهی کاری
اشتراکها