علیرضا صبوری علیرضا صبوری
مطالب
آشنایی با Gridify
Gridify چیست ؟

به طور خلاصه Gridify یک کتابخانه ساده و سریع است که عملیات‌های Filtering , Pagination و Sorting را با استفاده از شرط‌های متنی (string based) امکان پذیر میکند.
به طور مثال فرض کنید که یک API را برای دریافت لیست کاربران با نام UsersList نوشته‌اید. مثال:
 [HttpGet("[action]")]
 public async Task<IActionResult> UsersList()
 {
    var users =  await _dbContext.Users.AsNoTracking().ToListAsync();
    return Ok(users);
 }
طبیعتا بخش FrontEnd نرم افزار شما نیاز دارد این اطلاعات را به کاربر نمایش دهد. به همین جهت در بیشتر مواقع از یک گرید برای نمایش این اطلاعات استفاده میشود.
پس از دریافت اطلاعات از سرور با مشکلات زیر مواجه خواهیم شد.
  1. عدم پشتیبانی از Pagination: چون API، تمامی کاربران را به سمت کلاینت ارسال میکند؛ به همین جهت، هم با مشکل کارآیی (performance) در آینده مواجه میشویم و هم امکان گذاشتن صفحه بندی (Pagination) وجود نخواهد داشت. 
  2. عدم پشتیبانی از Sorting: اگر در گرید نمایش داده شده کاربر بخواهد اطلاعات را Sort کند، چون چنین امکانی هنوز برای API ما تعریف نشده، این عملیات سمت سرور امکان پذیر نیست.
  3. عدم پشتیبانی از Filtering: همیشه نمایش تمامی اطلاعات مفید نیست. در اکثر مواقع ما نیاز داریم تا قسمتی از اطلاعات را با شرطی خاص، برگردانیم. به طور مثال لیست کاربران فعال در سامانه یا لیست کاربران غیرفعال. 
این مشکلات بدون استفاده از هیچ کتابخانه‌ای قابل حل است ولی نه به سادگی؛ به طور مثال یا باید چندین API مختلف با امکانات مختلف بنویسیم، یا یک API را برای پشتیبانی از این موارد تغییر بسیار دهیم. من برای اینکه از بحث دور نشویم، به پیاده سازی نمونه دستی پشتیبانی از این موارد در اینجا نمی‌پردازم، چرا که اگر یکبار تلاشی را برای اینکار انجام داده باشیم، طبیعتا  مشکلات و کد کثیفی که در نهایت تولید شده است، یادآوری خواهد شد. 
برای رفع این مشکلات میتوان از کتابخانه Gridify استفاده کرد. مثال :
 [HttpGet("[action]")]
 public async Task<IActionResult> UsersList(GridifyQuery filter)
 {
    var users =  await _dbContext.Users.AsNoTracking().GridifyAsync(filter);
    return Ok(users);
 }
در مثال بالا با استفاده از کلاس GridifyQuery میتوانیم به کنترل هر سه مشکل Sorting - Pagination - Filtering سمت کلاینت بپردازیم. (در ادامه با این کلاس بیشتر آشنا خواهیم شد).

استفاده از Gridify به API‌ها محدود نمیشود. به طور کلی ما میتوانیم در هر نوع لیستی که امکان استفاده از IQueryable  را به ما میدهد از آن استفاده نماییم. 
فرض کنید در یک برنامه Console Application قصد داریم یک فیلتر را از کاربر دریافت کرده و آن را روی لیست خروجی خود اعمال کنیم. به دلیل اینکه امکان جستجوی متنی در دات نت وجود ندارد، برای انجام اینکار مجبور خواهیم شد که برای تک تک فیلدهایی که قرار است برای فیلترینگ پشتیبانی کنیم، یک query جداگانه بنویسیم؛ ولی این عملیات توسط کتابخانه Gridify امکان پذیر است. به طور مثال فرض کنید قصد داریم در لیست کاربران، کاربرانی را  با نام Ali، پیدا کنیم. 
var result = Users.AsQueryable().ApplyFiltering("name==Ali");
این کد دقیقا معادل کد زیر است.
var result = Users.AsQueryable().Where(q => q.Name == "Ali");
در اینجا با استفاده از کتابخانه Gridify ما توانستیم یک static Linq را به یک dynamic Linq که در runtime مقدار دهی خواهد شد، تغییر دهیم. به همین جهت استفاده از مورد اول در برنامه‌ی Console ما امکان پذیر است. تا اینجا ما با امکانات کلی این کتابخانه آشنا شدیم. در مقالات بعدی سعی میکنم به سایر امکانات این کتابخانه و بیشتر به جزئیات بپردازم. همینطور برای کسب اطلاعات بیشتر میتوانید به لینک زیر مراجعه نمایید.
‫۳ سال و ۲ ماه قبل، چهارشنبه ۳۰ تیر ۱۴۰۰، ساعت ۰۱:۴۵
فرید بکران فرید بکران
مطالب
بازسازی کد: جایگزینی نوع‌های داده‌های یک کلاس با زیر کلاس‌ها
یک پیاده سازی از کلاس، می‌تواند به طور ضمنی شامل دو یا چند نوع (Type) باشد. یکی از ساده‌ترین راه‌های پیاده سازی این حالت، استفاده از فیلدهایی برای نگهداری نوع اصلی داده‌ی کلاس است که اصطلاحا Type code نیز نامیده می‌شوند. به طور مثال پیاده سازی زیر را در نظر بگیرید. 

به طور مثال در کلاس بالا یک کارمند می‌تواند فروشنده یا مهندس باشد. پیاده سازی بالا این مورد را با استفاده از دو فیلد نشان داده‌است که در صورت true بودن، مقدار هریک از آن‌ها، نوع کلاس متناظر با آن خواهد بود.

مثلا اگر IsSalesman مقدار true داشته باشد، شیء ما کارمندی با نقش Salesman است و در صورتی که IsEngineer مقدار true داشته باشد ، شیء کارمند، نقش مهندس دارد. بماند که حالت‌های دیگری نیز برای مقادیر این فیلدها وجود دارند! 

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

اگر با همین فرمان کدنویسی را ادامه دهیم احتمالا با کلاسی روبرو خواهیم شد که پر است از گذاره‌های if else ، switch و یا مواردی از این دست؛ که ابدا شرایط دلپذیری برای دوستانی که قصد نگهداری از کد ما را دارند، نیست! 

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

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

  1. اگر type کد درونی کلاس از طریق سازنده به کلاس ارسال شده است، این سازنده را با یک متد سازنده (Factory method) جایگزین کنید. 
  2. به ازای هر مقدار از type کدهای درونی کلاس، یک زیر کلاس جدید بسازید. 
  3. تمامی استفاده‌ها از type کدهای درونی کلاس را بازسازی کرده و به کلاس‌های مربوط به خود منتقل کنید (احتمالا تمامی پیاده سازی‌هایی که if else یا switch ای بر روی مقدار type کدها دارند).
  4. از کلاس پایه، type کد را حذف کنید. 
  5. در صورت وجود تمامی استفاده‌ها از سازنده، کلاس اولیه را به استفاده از متد سازنده تغییر دهید. 
  6. کد را کامپایل و تست نمایید.
‫۵ سال و ۱۰ ماه قبل، دوشنبه ۱۹ آذر ۱۳۹۷، ساعت ۱۴:۱۵
فرید بکران فرید بکران
مطالب
بازسازی کد: جایگزینی داده با شیء (Replace data with object)
بازسازی کد جایگزینی داده با شیء، معمولا در طراحی موجودیت‌های قابل ذخیره و بازیابی سیستم‌های اطلاعاتی مورد نیاز قرار می‌گیرید. این بازسازی کد معمولا زمانی مورد نیاز است که آیتم داده‌ای نیاز به اطلاعات بیشتر یا رفتاری خاص دارد. در این صورت باید آن آیتم داده‌ای را به شیء از کلاس یا ساختار (struct) تبدیل کرد. 
معمولا زمانیکه توسعه محصول انجام می‌گیرد، ممکن است آیتم‌های داده‌ای در ابتدا ساده دیده شوند و طراحی ساده‌ای برای آنها در نظر گرفته شود. به طور مثال در یک سیستم فرضی رسیدگی به تیکت، ممکن است با اقلام اطلاعاتی مانند آیتم‌های زیر روبرو باشیم:  
  •  شماره تلفن، به صورت رشته کاراکتری 
  • آدرس، به عنوان رشته کاراکتری 
  • نام مسئول رسیدگی به تیکت، به صورت رشته کاراکتری  
با توجه به مثال بالا، در طراحی اولیه AgentName، فیلدی از نوع رشته کاراکتری برای نگهداری نام مسئول رسیدگی به تیکت در نظر گرفته شده است (فرض می‌کنیم در این طراحی موضوعات مربوط به نرمال سازی پایگاه‌های داده را در نظر نگرفته‌ایم و تکرار شدن نام مسئول رسیدگی به تیکت اشکالی نداشته‌است). کلاس زیر نشان دهنده چنین طراحی‌ای است.  

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

در چنین شرایطی، یک اقدام ممکن، افزودن اقلام اطلاعاتی مورد نیاز در همان مکان آیتم قبلی است؛ به طور مثال اگر نام مسئول بر روی موجودیت تیکت باشد، شماره تلفن مسئول نیز در همان موجودیت تیکت اضافه شود.  

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

این بازسازی کد دو مزیت کلی دارد:  

  • راه را برای توسعه آینده آیتم‌های داده‌ای باز می‌کند
  • از تکرار آیتم‌های داده‌ای جلوگیری می‌کند (به طور مثال زمانیکه از پایگاه داده‌های رابطه‌ای جهت ذخیره سازی، استفاده شود)  
در مثال بالا علارغم اینکه قادر بودیم آیتم اطلاعاتی مسئول رسیدگی را به صورت ساختار (struct) تعریف کنیم، این آیتم اطلاعاتی را به صورت کلاس تعریف کردیم. تعریف به صورت کلاس امکان استفاده از رفرنس را به‌جای مقدار شیء، به ما خواهد داد. در اکثر بازسازی‌های کد، استفاده از کلاس‌ها مزیت‌های بیشتری نسبت به استفاده از ساختار دارد. برای مطالعه بیشتر در این مورد می‌توانید به اینجا مراجعه نمایید.  
‫۶ سال و ۸ ماه قبل، چهارشنبه ۱۱ بهمن ۱۳۹۶، ساعت ۱۲:۰۵
علیرضا آرانی علیرضا آرانی
مطالب
الگوریتم های داده کاوی در SQL Server Data Tools (SSDT) - قسمت اول (مقدمه)
پیشتر مطالبی در رابطه با مفاهیم مخزن داده و داده کاوی در سایت آمده است: ^ و ^ و ^.

در این سری مقالات به معرفی الگوریتم‌های داده کاوی مایکروسافت و نحوه کار کردن با آن‌ها در محیط SQL Server Data Tools (SSDT)  می‌پردازیم. بیشتر متن مقاله ترجمه آزاد از کتاب معروف  Data Mining with Microsoft SQL Server 2008 می باشد که یکی از بهترین کتاب‌ها در زمینه داده کاوی است. از آنجائیکه دسته بندی الگوریتم‌های داده کاوی در SQL Server 2016 نسبت به SQL Server 2008 قدری متفاوت می‌باشد و کتاب فوق به دلیل ورژن SQL قدیمی‌تر، این موضوع را درنظر نگرفته است، بنابراین تغییرات ورژن جدید دسته بندی الگوریتم‌ها نیز لحاظ شده است. جهت درک بهتر مطالب، سعی شده‌است مثال و توضیحاتی براساس تجربه کاری  آورده شود.
برای دریافت SSDT می‌توانید به اینجا مراجعه نمایید.
پس از دریافت و نصب SSDT می‌توان به Visual Studio مراجعه نمود و یک پروژه Analysis Services Multidimensional and Data Mining یا به اختصار  SSAS-M را به شکل زیر ایجاد کرد.

 پس از ایجاد یک پروژه SSAS-M می‌توان در بخش Mining Structure یک ساختار داده کاوی را به شکل زیر ایجاد نمود.

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

در صفحه بعد الگوریتم موردنظر را انتخاب می‌نماییم.

بدیهی است که پس از ساخت ساختار داده کاوی می‌توان الگوریتم‌های دیگری را نیز برای مدل کردن مخزن داده به کار برد.

در این مقاله فرض شده است که خواننده نحوه ساخت  Cube  و  Dimension  را در یک پروژه SSAS-M توسط SSDT ، می‌داند. در صورتیکه به داده کاوی و هوش تجاری علاقمند هستید و به مقدمات بیشتری در رابطه با مطالب فوق نیاز دارید، پیشنهاد می‌شود که فصل‌های یک، سه و چهار کتاب فوق را جهت آشنایی بیشتر مطالعه نمایید.

همانطور که در شکل آخر نیز نشان داده شده است SSDT دارای الگوریتم‌های زیر است:

  • Microsoft_Naive_Bayes
  • Microsoft_Decision_Trees
  • Microsoft_Linear_Regression
  • Microsoft_Clustering
  • Microsoft_ Association_Rules
  • Microsoft_Neural_Network
  • Microsoft_Logistic_Regression
هدف این سری مقالات که به امید خدا در آینده منتشر خواهد شد، آشنایی با الگوریتم‌های داده کاوی فوق و نحوه مدل کردن مخزن داده توسط این الگوریتم‌ها و در نهایت چگونگی تفسیر مدل های داده کاوی تولید شده، می‌باشد.
‫۷ سال و ۵ ماه قبل، دوشنبه ۱ خرداد ۱۳۹۶، ساعت ۱۵:۳۰
سید رئوف مدرسی سید رئوف مدرسی
مطالب
تبادل داده‌ها بین لایه‌ها؛ قسمت آخر

روش سوم: DTO (Data transfer objects) 

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

در این روش ما سعی می‌کنیم طراحی کلاس‌ها را به اصطلاح مسطح ( flatten) کنیم تا بر مشکل double loop که در قسمت قبل بحث کردیم غلبه کنیم. در کد ذیل مشاهده می‌کنید که چگونه کلاس CusomerDTO از CustomerEntity ،  مشتق می‌شود و کلاس Address را با CustomerEntity ادغام می‌کند؛ تا برای افزایش سرعت لود و نمایش داده‌ها، یک کلاس de-normalized شده ایجاد نماید.  

public class CustomerDTO : CustomerEntity 
{
    public AddressEntity _Address = new AddressEntity();
}

در کد ذیل می‌توانید مشاهده کنید که چگونه با استفاده از فقط یک loop یک کلاس de-normalized شده را پر می‌کنیم.  

foreach (DataRow o1 in oCustomers.Tables[0].Rows)
{
CustomerDTO o = new CustomerDTO();
o.CustomerCode = o1[0].ToString();
o.CustomerName = o1[1].ToString();
o._Address.Address1 =  o1[2].ToString();
o._Address.Address2 = o1[3].ToString();
obj.Add(o);
}

UI هم به راحتی می‌تواند DTO را فراخوانی کرده و دیتا را دریافت کند.


مزایا و معایب روش DTO 

یکی از بزرگترین مزایای این روش سرعت زیاد در بارگذاری اطلاعات، به دلیل استفاده کردن از ساختار de-normalized می‌باشد. اما همین مسئله خود یک عیب محسوب می‌شود؛ به این دلیل که اصول شئ گرایی را نقض می‌کند.


روش چهارم: Hybrid approach (Entity + DTO) 

از یک طرف کلاس‌های Entity که دنیای واقعی را مدل خواهند کرد و همچنین اصول شئ گرایی را رعایت می‌کنند و از یک طرف دیگر DTO نیز یک ساختار flatten را برای رسیدن به اهداف  کارآیی دنبال خواهند کرد. خوب، به نظر می‌رسد که بهترین کار استفاده از هر دو روش و مزایای آن روش‌ها باشد. 

زمانیکه سیستم، اهدافی مانند انجام اعمال CRUD را دنبال می‌کند و شما می‌خواهید مطمئن شوید که اطلاعات، دارای integrity می‌باشند و یا اینکه می‌خواهید این ساختار را مستقیما به کاربر نهایی ارائه دهید، استفاده کردن از روش (Entity) به عنوان یک روش normalized می‌تواند بهترین روش باشد. اما اگر می‌خواهید حجم بزرگی از دیتا را نمایش دهید، مانند گزارشات طولانی، بنابراین استفاده از  روش DTO با توجه به اینکه یک روش de-normalized به شمار می‌رود بهترین روش می‌باشد.

کدام روش بهتر است؟

Non-uniform : این روش برای حالتی است که متد‌های مربوط به data access تغییرات زیادی را تجربه نخواهند کرد. به عبارت دیگر، اگر پروژه‌ی شما در آینده دیتابیس‌های مختلفی را مبتنی بر تکنولوژی‌های متفاوت، لازم نیست پشتیبانی کند، این روش می‌تواند بهترین روش باشد.

Uniform : Entity, DTO, or hybrid : اگر امکان دارد که پروژه‌ی شما با انواع مختلف دیتابیس‌ها مانند Oracle و Postgres ارتباط برقرار کند، استفاده کردن از این روش پیشنهاد می‌شود.   
‫۹ سال و ۲ ماه قبل، چهارشنبه ۴ شهریور ۱۳۹۴، ساعت ۰۱:۱۵
علی یگانه مقدم علی یگانه مقدم
مطالب
آشنایی با CLR: قسمت هجدهم
در قسمت قبلی با نحوه‌ی نسخه بندی اسمبلی‌ها آشنا شدیم؛ ولی به غیر از نسخه بندی، فرهنگ (culture) هم قسمتی از عوامل شناسایی یک اسمبلی است. به عنوان نمونه من میتوانم یک اسمبلی داشته باشم که برای زبان آلمانی، انگلیسی آمریکایی، انگلیسی بریتانیایی و ... آماده شده است.
شناسایی فرهنگ یک اسمبلی از طریق یک رشته است که شامل یک تگ اصلی و ثانویه طبق استاندارد RFC1766 می‌باشد. جدول زیر تعدادی از این تگ‌ها را نمایش می‌دهد.
 تگ اولیه  تگ ثانویه  فرهنگ مربوطه 
 De -  آلمانی 
 De  AT  آلمانی اتریشی
 De  CH  آلمانی سوئیسی
 En  -  انگلیسی
 En  GB  انگلیسی بریتانیا
 En  US  انگلیسی آمریکایی
در حالت عادی که یک اسمبلی را که تنها شامل کد می‌شود، دارید برای آن culture تعریف نمی‌شود. چون مشخصه‌ی خاصی ندارد که به آن فرهنگ خاصی هم تعلق بگیرد. به این اسمبلی‌ها Culture Neutral یا خنثی می‌گویند.
حال اگر شما در حال طراحی برنامه‌ای هستید که منابع Resources شامل مشخصه‌های فرهنگی و منطقه‌ای می‌شوند، مایکروسافت به شدت توصیه می‌کند که بحث کد را از منابع جدا کرده و اسمبلی هایشان جدا شوند. یک اسمبلی برای کدها و منابع مشترک استفاده شود که هیچ خصوصیت فرهنگی و منطقه‌ای خاصی ندارد. حال یک یا چند اسمبلی جداگانه برای منابع ساخته که هر کدام از آن‌ها به فرهنگ و منطقه‌ی خاصی اشاره می‌کنند. به این نوع اسمبلی‌ها Satellite Assembly یا اسمبلی ماهواره‌ای گویند.
عموما از ابزار AL برای ساخت اسمبلی‌های ماهواره ای استفاده می‌شود. دلیل آن هم اینست که این اسمبلی‌ها چون عموما کدی را شامل نمی‌شوند، ساخت آن‌ها از طریق کامپایلر ممکن نیست. برای معرفی یک اسمبلی ماهواره‌ای باید از سوئیچ c یا culture استفاده کرد و به عنوان ورودی، این سوئیچ تگ‌ها را به آن نسبت داد. 
/c[ulture]:En-US
بعد از اینکه اسمبلی ساخته شد در مسیر برنامه، در یک زیردایرکتوری که با همان شناسه‌ی تگ‌ها نام گرفته است، ذخیره می‌کنیم. به عنوان مثال اگر مسیر زیر، مسیر برنامه ما باشد: 
C:\MyApp
اسمبلی ماهواره‌ای با مشخصات بالا باید در مسیر زیر قرار بگیرد:
C:\MyApp\en-US
در صورتی که قصد دارید در زمان اجرا به منابع یک اسمبلی ماهواره‌ای دسترسی پیدا کنید می‌توانید از کلاس زیر استفاده کنید:
System.Resources.ResourceManager
به هر حال اگر کدهای شما در فرهنگ و منطقه تاثیر دارند و دوست دارید اسمبلی کدها هم به عنوان یک اسمبلی ماهواره‌ای شناخته شوند از خصوصیت زیر برای معرفی اسمبلی خود استفاده کنید: 
 System.Reflection.AssemblyCultureAttribute

===============
[assembly:AssemblyCulture("de­-CH")]
در AL هم از سوئیچ Culture/ استفاده می‌شود. به طور عادی شما نباید یک اسمبلی بسازید که به اسمبلی ماهواره ای اشاره می‌کند و جداول متادیتا اسمبلی‌ها باید به اسمبلی‌های خنثی اشاره کنند. اگر شما قصد دسترسی به اعضاء و خصوصیات یک اسمبلی ماهواره‌ای را دارید باید از طریق Reflection که در آینده در مورد آن صحبت خواهد شد اینکار را انجام دهید.( در  کتاب جفری ریچر   به فصل بیست و سوم Assembly Loading and Reflection مراجعه شود)
‫۹ سال و ۲ ماه قبل، دوشنبه ۲ شهریور ۱۳۹۴، ساعت ۰۵:۳۵
علی یگانه مقدم علی یگانه مقدم
مطالب
آشنایی با CLR: قسمت سوم
در اینجا ما زیاد بر روی جزئیات یک اسمبلی مانور نمی‌دهیم و آن را به آینده موکول می‌کنیم و فقط مقداری از مباحث اصلی را ذکر می‌کنیم.

ترکیب ماژول‌های مدیریت شده به یک اسمبلی

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

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

همه کارهای تولید اسمبلی به صورت خودکار اتفاق می‌افتد. ولی در صورتیکه قصد دارید فایلی را به اسمبلی به طور دستی اضافه کنید نیاز است که به دستورات و ابزارهای کامپایلر آشنایی داشته باشید.

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

یک ماژول اسمبلی شامل اطلاعاتی در رابطه با ارجاعاتش است؛ به علاوه ورژن خود اسمبلی. این اطلاعات سبب می‌شوند که یک اسمبلی خود تعریف self-describing شود که به بیان ساده‌تر باعث می‌شود CLR وابستگی‌های یک اسمبلی را تشخیص داده تا ترتیب اجرای آن‌ها را پیدا کند. نه دیگر نیازی به اطلاعات اضافی در ریجستری است و نه در Active Directory Domain Service یا به اختصار ADDS.

از آنجایی که هیچ اطلاعاتی اضافی نیست، توزیع ماژول‌های مدیریت شده راحت‌تر از ماژول‌های مدیریت نشده است.

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

‫۹ سال و ۴ ماه قبل، یکشنبه ۲۴ خرداد ۱۳۹۴، ساعت ۰۵:۴۵
پگاه پگاه
مطالب
اولویت بندی: رمز موفقیت در برنامه ریزی به روش چابک

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

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

همه‌ی ما با اولویت بندی آشنا هستیم و معمولا با اختصاص دادن شماره به هر مورد، آن مورد را اولویت بندی می‌کنیم. به طور مثال، «نوشتن مقاله برنامه ریزی به روش چابک» اولویت 2، «شبیه سازی الگوریتم همزمان سازی» اولویت 1 و «دویدن به مدت 30 دقیقه» اولویت 3، مثال‌هایی از اولویت بندی به روش سنتی است. اما آقای  Meier .J.D  در کتاب خودش روش مؤثرتری را که بر اساس بایدها و نبایدها بنا شده است، پیشنهاد می‌کند که در ادامه به آن اشاره می‌کنیم.


اولویت‌ها در مدل چابک 

در این روش سه درجه از اولویت وجود دارند. درجه‌ی اول، کارهایی هستند که حتما باید انجام بگیرند. درجه دوم، کارهایی هستند که بهتراست (بایستی) انجام شوند و درجه سوم، کارهایی هستند که می‌شود انجام شوند و یا نشوند. آقای Meier این سه درجه را به ترتیب با سه واژه " Must "، " Should " و " Could " مشخص کرده است.


روش اولویت بندی در مدل چابک

برای تهیه سه دیدگاه هفته و خروجی روزانه، ابتدا لیستی از اهداف و کارهای مورد نظر خود را تهیه کنید. سپس از خود بپرسید: (1) کدامیک از اقلام این لیست را باید انجام دهید؟ (2) کدامیک را بهتر است که انجام دهید؟ (3) کدامیک را می‌توانید انجام دهید؟ پس از مشخص کردن اولویت‌ها، سه خروجی روزانه و یا سه دیدگاه هفتگی خود را از میان اقلامی که در دسته اول، یعنی بایدها قرار می‌گیرند، انتخاب کنید.

مزایای اولویت بندی

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

2-  با تعیین اولویت‌ها برای هفته و هر روز خود، شما حداقل کارهایی را که باید برای هفته یا هر روز خود انجام دهید، مشخص کرده‌اید. زمانیکه این بایدها را انجام دهید، بقیه هفته و یا روز برای شما خواهد بود و می‌توانید از آن لذت ببرید!

3- اولویت بندی به شما قابلیت انعطاف می‌دهد. اگر یک کار یا فعالیت جدید پیش بیاید مثلا  اگر رییس شما کار جدیدی را به شما محول کند، شما می‌توانید با تعیین درجه اولویت آن کار و مقایسه آن با بایدهای درحال انجام (سه خروجی روزانه یا دیدگاه هفتگی) تصمیم بگیرید که فعالیت محول شده جدید را انجام دهید یا انجام آن را به زمان دیگری موکول کنید.

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

‫۹ سال و ۹ ماه قبل، یکشنبه ۱۹ بهمن ۱۳۹۳، ساعت ۰۵:۴۵
دادگر دادگر
مطالب
SQL Injection چیست؟
برای ایجاد امنیت در نرم افزار، باید ابتدا مشکلات رایج را بدانیم. یکی از رایجترین نقائص امنیتی نرم افزارها SQL Injection می‌باشد.
SQL Injection در لغت به معنی تزریق کد SQL می‌باشد. در اصلاح یعنی تزریق دستوراتی به کد SQL تولیدی یک نرم افزار به نحوی که به جای عمل مورد انتظار برنامه نویس آن، کاری را که ما می‌خواهیم انجام دهد. مثلا به جای اینکه هنگام ورود به برنامه وقتی کاربر مشخصات کاربری خود را وارد می‌کند، مشخصات کاربری را به نحوی وارد کنیم که بتوانیم بعنوان مدیر سامانه و یا یک کاربر معمولی بدون داشتن کلمه عبور وارد سیستم شویم.
البته همیشه از این نوع حمله برای ورود به سیستم استفاده نمی‌شود. یعنی ممکن است هکر به عنوان یک کاربر عادی وارد سیستم شود ولی با به کاربردن دستورات خاص SQL در بخش‌های مختلف، بتواند اطلاعاتی را حذف نماید.
خوب حالا این کار چگونه انجام می‌شود؟
فرض کنید برنامه نویسی کد چک نام کاربری را اینگونه نوشته باشد:
SqlCommand cmd=new SqlCommand ("select count(*) from login where user='"+userName+"' and pass='"+password+"'",con);

فکر نکنید خوب این نوع کد نویسی مربوط به زمان تیرکمون شاه است! همین امروز در نظارت از یک پروژه به این نکته برخورد کردم! دلیل نوشتن این مقاله هم همین کد بود.
خوب حالا مگر کد بالا چه مشکلی دارد؟ ;) اگر کاربر در نامه کاربری و کلمه عبور مقادیر معمولی وارد کند (مانند admin, salam123) کد sql تولید شده به شکل زیر خواهد بود:

select count(*) from login where user='admin' and pass='salam123'

خوب حالا اگر کاربر کمی با ورودی‌ها بازی کند. به عنوان مثال فرض کنید به جای کلمه عبور تایپ کند
' or 1=1 --

نتیجه حاصله خواهد بود:
select count(*) from login where user='admin' and pass='' or 1=1 --'

با وارد کردن این دستور کاربر بدون داشتن کلمه عبور خواهد توانست وارد سیستم شود. موردی که توضیح دادم پایه مسئله بود. ما قصد آموزش هک نداریم ولی داشتن اطلاعات پایه لازم است. ممکن است فردی بگوید خوب ما قبل از تولید همچین کدی ' را از رشته کلمه عبور حذف می‌کنیم. خیلی خوب ولی اگر هکر از معادل unicode آن استفاده کرد چه؟ اگر و اگر و اگر...
راه حل‌های متعددی برای این موضوع پیشنهاد شده است. ولی ساده‌ترین و کارآمد‌ترین راه، استفاده از پارامترها می‌باشد که علاوه بر حذف این خطر باعث ایجاد و ذخیره query plan در sql server می‌شود و اجرای این query را در آینده تسریع می‌کند.
بنابراین می‌توان کد فوق را به صورت زیر بازنویسی کرد:
SqlCommand cmd=new SqlCommand ("select count(*) from login where user=@u and pass=@p",con);

cmd.Parameters.Add("@u", SqlDbType.Varchar, 10).Value=TextLogin.Text.Trim();

cmd.Parameters.Add("@p", SqlDbType.Varchar,10).Value=TextPwd.Text.Trim();
‫۱۰ سال و ۱۰ ماه قبل، سه‌شنبه ۱۰ دی ۱۳۹۲، ساعت ۰۳:۳۵
محمد پهلوان محمد پهلوان
مطالب
معماری پایگاه داده چند مستاجری (Multi-Tenant Data Architecture)
 اعتماد و یا فقدان آن، عامل شماره یک مسدود کردن استفاده از نرم افزار به عنوان خدمات است. معماری پایگاه داده چند مستاجری برای رسیدگی به مشکل نرم افزار به عنوان سرویس (SaaS) که می‌تواند خدمات به تعدادی کلاینت ارائه کند استفاده می‌شود . معماری دیتابیس چند مستاجری وقتی مفید است که یک نمونه از دیتابیس به تعدادی کلاینت خدمات دهد. وقتی که نرم افزار‌های محلی نصب می‌کنید نرم افزارهای به عنوان یک سرویس با مشتریان متمرکز، دسترسی به داده‌ها مبتنی بر شبکه با سربار کمتر را فراهم می‌کنند. اما به منظور برخورداری بیشتر از مزیت‌های یک نرم افزار سرویس، یک سازمان باید از سطحی از کنترل روی داده صرفنظر کند و به فروشنده نرم افزار جهت نگهداری و امنیت به دور از چشم آنها اعتماد کند.

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

  سه روش مدیریت چند مستاجری داده
  1. دیتابیس‌های جداگانه برای هر مستاجر
  2. دیتابیس مشترک و schema جداگانه برای هر مستاجر
  3. دیتابیس مشترک و schema مشترک 

  انتخاب روش مناسب برای برنامه شما به عوامل زیر بستگی دارد :
  • سایز دیتابیس هر مستاجر
  • تعداد مستاجران
  • تعداد کاربران هر مستاجر
  • نرخ رشد مستاجر
  • نرخ رشد دیتابیس مستاجر
  • امنیت  
  • هزینه

1) دیتابیس‌های جداگانه برای هر مستاجر :
ذخیره سازی داده‌های مستاجران در دیتابیس‌های جداگانه ساده‌ترین روش است. در این روش هر مستاجر یک دیتابیس دارد. منابع و کدهای برنامه معمولا در سرور بین همه مستاجران مشترک است اما هر مستاجر مجموعه ای از داده دارد که بطور منطقی از سایر مستاجران جدا شده است.

  مزایا :
  • امنیت بیشتر
  • سهولت سفارشی سازی برای هر مستاجر
  • سهولت نگهداری ( Backup و Restore ) برای هر مستاجر

معایب:
  • برای نگهداری سخت افزار قوی مورد نیاز است
  • این روش هزینه بیشتری برای تجهیزات ( Backup و Restore ) برای هر مستاجر دارد

  2)   دیتابیس مشترک و schema جداگانه برای هر مستاجر :
خدمات دهی به چندین مستاجر در یک دیتابیس مشترک اما هر مستاجر یک مجموعه از جداول گروهبندی شده دارد که با Schema جدا شده است که برای هر مستاجر الزامی است.

مزایا :
  • برای دیتابیس برنامه‌های کوچک مناسب است. وقتی تعداد جداول برای هر مشتری کم است
  • هزینه کمتری نسبت به روش اول دارد
  • برای مشتریانی که نگران امنیت هستند، سطح منطقی مناسبی برای جداسازی داده ه وجود دارد

معایب:
  • اطلاعات مستاجران در صورت بروز خطا به سختی restore می‌شود
  • مدیریت آن برای دیتابیس‌های بزرگ مشکل است

  3)   دیتابیس مشترک و schema مشترک :

این روش شمامل یک دیتابیس و یک مجموعه از جداول برای چندین مستاجر است. داده‌های جدول می‌تواند شامل رکورد‌های هر مستاجر باشد

مزایا :
  • در مقایسه با روش قبلی، کمترین هزینه سخت افزاری را دارد
  • می‌تواند مستاجران بیشتری رادر هر سرور پشتیبانی کند
  • قابلیت بروز رسانی آسان در یک جا برای همه مستاجران
  • مدیریت آسان دیتابیس و خطا و Backup و Restore
معایب:
  • امنیت بیشتری مورد نیاز است تا مطمئن شوید هیچکس به اطلاعات سایر مستاجران دسترسی ندارد.
  • می‌تواند روی کارایی کوئری‌ها تاثیر بگذارد چون تعداد رکورد‌ها زیاد است.
  • بروزرسانی و سفارشی کردن فقط برای یک مستاجر سخت است
 
منابع :
http://msdn.microsoft.com/en-us/library/aa479086.aspx
http://www.codeproject.com/Articles/51334/Multi-Tenants-Database-Architecture   
‫۱۰ سال و ۱۱ ماه قبل، دوشنبه ۱۱ آذر ۱۳۹۲، ساعت ۱۳:۱۰