مطالب
مقایسه و بررسی پوشه‌های Bin و Obj در برنامه‌های NET.
زمانیکه شما یک برنامه‌ی دات نتی نوشته شده به زبان سی شارپ را کامپایل می‌کنید، دو پوشه‌ی bin و obj را مشاهده می‌کنید. در این مطلب، اهمیت و تفاوت این دو پوشه را بررسی می‌کنیم. این پوشه‌ها حاوی کد‌های کامپایل شده‌ی IL می‌باشند. 

فرآیند کامپایل به دو مرحله‌ی کامپایل سورس کد و همچنین ایجاد پیوند (linking) بین فایل‌های کامپایل شده تقسیم می‌شود.
به دیاگرام زیر دقت نمائید:
• در مرحله‌ی کامپایل، هر یک از سورس فایل‌ها، بصورت مجزا کامپایل می‌شود و به ازای هر سورس فایل، یک فایل مجزای کامپایل شده تولید می‌شود. بدین معنا که اگر دو فایل داشته باشیم، دو کد مستقل کامپایل شده نیز تولید می‌شوند.
• در مرحله‌ی متصل کردن (linking)، همه‌ی فایل‌های کامپایل شده به یک اسمبلی واحد کامپایل می‌شوند که این اسمبلی می‌تواند از نوع DLL و یا EXE باشد.

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

اما سؤالی که در ذهن ایجاد می‌شود این است که چرا این فرآیند در دو مرحله انجام می‌شود و چرا فرآیند کامپایل در یک مرحله انجام نمی‌شود. با انجام 2 مرحله‌ای فرآیند کامپایل، می‌توان از قابلیت کامپایل شرطی (Conditional Compiling) بهره‌مند شد.
زمانیکه یک پروژه‌ی بزرگ را کامپایل می‌کنیم، انتظار داریم تنها فایل‌هایی را که تغییر کرده‌اند، کامپایل شوند و در پوشه‌ی obj، ما هر فایل کامپایل شده را بصورت مجزا داریم. در نتیجه می‌توانیم تشخیص دهیم  که چه فایل‌هایی تغییر کرده‌اند و تنها آنها را کامپایل می‌کنیم که این کار باعث افزایش سرعت فرآیند کامپایل می‌شود.

بطور خلاصه در پوشه‌ی obj، ما به ازای هر سورس فایل، یک فایل کامپایل شده داریم؛ اما در پوشه‌ی bin تنها یک فایل یکپارچه شده را خواهیم داشت.

نظرات مطالب
طراحی افزونه پذیر با ASP.NET MVC 4.x/5.x - قسمت سوم
راه حل: نباید این‌کار را انجام دهید.
علت:
- اگر افزونه‌ای قرار هست برنامه‌ی اصلی را تغدیه کند - مثلا اعتبارسنجی - نام آن افزونه نیست و نباید به صورت افزونه تعریف شود. برنامه‌ی اصلی بجز بارگذاری افزونه‌ها هیچ کار دیگری قرار نیست با جزئیات آن‌ها به صورت مستقیم انجام دهد.
- اگر افزونه‌ای وابسته‌است به افزونه‌ی دیگر، نام اینکار افزونه نویسی نیست.
- شما قبل از اینکه بخواهید وارد این مبحث شوید، نیاز است کمی در مورد برنامه‌های افزونه پذیر موجود (در حالت کلی) مطالعه کنید و بررسی کنید که مثلا اگر یک برنامه‌ی پخش music افزونه پذیر است، افزونه‌ی A آن که توسط فرد X تهیه شده، آیا قرار است از امکانات افزونه‌ی B که توسط فرد Y تهیه شده‌است، استفاده کند؟ چنین کاری اساسا بی‌مفهوم است و طراحی افزونه پذیر نام ندارد. آیا افزونه‌ی A فایرفاکس از افزونه‌ی B آن استفاده می‌کند و به آن وابسته‌‌است؟ خیر.
- اگر قرار هست افزونه‌ها به یک سری اطلاعات مشترک دسترسی پیدا کنند، این اطلاعات باید مشترک باشند و مستقل از هر کدام از افزونه‌ها.

در مثالی که ارائه شد، اگر هدف کوئری گرفتن از لیست خبرهای یک کاربر است، این کار فقط باید در افزونه‌ی News انجام شود (چون اگر قرار باشد سایر افزونه‌ها به ریز اطلاعات news دسترسی داشته باشند که ضرورتی به افزونه تعریف کردن آن نبود) و به این صورت:
 var userNewsList =  _news.Include(x=>x.User).Where(x=>x.UserId == 1).ToList();
مطالب
ASP.NET MVC #6

آشنایی با انواع ActionResult

در قسمت چهارم، اولین متد یا اکشنی که به صورت خودکار توسط VS.NET به برنامه اضافه شد، اینچنین بود:

using System.Web.Mvc;

namespace MvcApplication1.Controllers
{
public class HomeController : Controller
{
//
// GET: /Home/
public ActionResult Index()
{
return View();
}
}
}

توضیحات تکمیلی مرتبط با خروجی از نوع ActionResult ایی را که مشاهده می‌کنید، در این قسمت ارائه خواهد شد.
رفتار یک کنترلر توسط متدهایی که در آن کلاس تعریف می‌شوند، مشخص می‌گردد. هر متد هم از طریق یک URL مجزا قابل دسترسی و فراخوانی خواهد بود. این متدها که به آن‌ها اکشن نیز گفته می‌شود باید عمومی بوده، استاتیک یا متد الحاقی (extension method) نباشند و همچنین دارای پارامترهایی از نوع ref و out نیز نباشند.
هر درخواست رسیده، به یک کنترلر و متدی عمومی در آن توسط سیستم مسیریابی، نگاشت خواهد شد. اگر علاقمند باشید که در یک کلاس کنترلر، متدی عمومی را از این سیستم خارج کنید، تنها کافی است آن‌را با ویژگی (attribute) به نام NonAction مزین کنید:

using System.Web.Mvc;

namespace MvcApplication2.Controllers
{
public class HomeController : Controller
{
[NonAction]
public string ShowData()
{
return "Text";
}

public ActionResult Index()
{
ViewBag.Message = string.Format("{0}/{1}/{2}",
RouteData.Values["controller"],
RouteData.Values["action"],
RouteData.Values["id"]);
return View();
}

public ActionResult Search(string data = "*")
{
// do something ...
return View();
}
}
}

چند نکته در این مثال قابل ذکر است:
الف) در اینجا اگر شخصی آدرس http://localhost/home/showdata را درخواست نماید، با توجه به استفاده از ویژگی NonAction، با پیغام یافت نشد یا 404 مواجه می‌گردد.
ب) صرفنظر از پارامترهای یک متد و ساختار کلاس جاری، اطلاعات مسیریابی از طریق شیء RouteData.Values نیز در دسترس هستند که نمونه‌ای از آن‌را در اینجا بر اساس مقادیر پیش فرض تعاریف مسیریابی یک پروژه ASP.NET MVC ملاحظه می‌نمائید.
ج) در متد Search، از قابلیت امکان تعریف مقداری پیش فرض جهت آرگومان‌ها در سی شارپ 4 استفاده شده است. به این ترتیب اگر شخصی آدرس http://localhost/home/search را وارد کند، چون پارامتری را ذکر نکرده است، به صورت خودکار از مقدار پیش فرض آرگومان data استفاده می‌گردد.


انواع Action Results در ASP.NET MVC

در ASP.NET MVC بجای استفاده مستقیم از شیء Response، از شیء ActionResult جهت ارائه خروجی یک متد استفاده می‌شود و مهم‌ترین دلیل آن هم مشکل بودن نوشتن آزمون‌های واحد برای شیء Response است که وهله سازی آن مساوی است با به کار اندازی موتور ASP.NET و Http Runtime آن توسط یک وب سرور (بنابراین در ASP.NET MVC سعی کنید شیء Response را فراموش کنید).
سلسه مراتب ActionResult‌های قابل استفاده در ASP.NET در تصویر زیر مشخص شده‌اند:


و در مثال زیر تقریبا انواع و اقسام ActionResult‌های مهم و کاربردی ASP.NET MVC را می‌توانید مشاهده کنید:

using System.Web.Mvc;

namespace MvcApplication2.Controllers
{
public class ActionResultsController : Controller
{
//http://localhost/actionresults/welcome
public string Welcome()
{
return "Hello, World";
}

//http://localhost/actionresults/index
public ActionResult Index() // or ContentResult
{
return Content("Hello, World");
}

//http://localhost/actionresults/SendMail
public void SendMail()
{
}

public ActionResult SendMailCompleted() // or EmptyResult
{
// do whatever
return new EmptyResult();
}

public ActionResult GetFile() // or FilePathResult
{
return File(Server.MapPath("~/content/site.css"), "text/css", "mySite.css");
}

public ActionResult UnauthorizedStatus() // or HttpStatusCodeResult/HttpUnauthorizedResult
{
return new HttpUnauthorizedResult("You need to login first.");
}

public ActionResult Status() // or HttpStatusCodeResult
{
return new HttpStatusCodeResult(501, "Server Error");
}

public ActionResult GetJavaScript() // or JavaScriptResult
{
return JavaScript("...JavaScript...");
}

public ActionResult GetJson() // or JsonResult
{
var obj = new { prop1 = 1, prop2 = "data" };
return Json(obj, JsonRequestBehavior.AllowGet);
}

public ActionResult RedirectTo() // or RedirectResult
{
return RedirectPermanent("http://www.site.com");
//return RedirectToAction("Home", "Index");
}

public ActionResult ShowView() // or ViewResult
{
return View();
}
}
}

چند نکته در این مثال وجود دارد:
1) مثلا متد GetJavaScript را درنظر بگیرید. در این متد خاص، چه بنویسید public ActionResult GetJavaScript یا بنویسید public JavaScriptResult GetJavaScript تفاوتی نمی‌کند. در سایر موارد هم به همین ترتیب است. علت را در تصویر سلسله مراتبی ActionResult‌ها می‌توان جستجو کرد. تمام این کلاس‌ها نوعی ActionResult هستند و از یک کلاس پایه به ارث رسیده‌اند.
2) مثلا ContentResult شبیه به همان Response.Write سابق ASP.NET عمل می‌کند. علت وجودی آن هم عدم وابستگی مستقیم به شیء Response و ساده‌تر سازی نوشتن آزمون‌های واحد برای این نوع اکشن متدها است.
3) منهای متد آخری که نمایش داده شده (ShowView)، هیچکدام از متدهای دیگر نیازی به View متناظر ندارند. یعنی نیازی نیست تا روی متد کلیک راست کرده و Add view را انتخاب کنیم. چون در همین متد کنترلر، کار Response به پایان می‌رسد و مرحله بعدی ندارد. مثلا در حالت return File، یک فایل به درون مرورگر کاربر Flush خواهد شد و تمام.
4) متد Welcome و متد Index در اینجا به یک صورت تفسیر می‌شوند. به این معنا که اگر خروجی متد تعریف شده در یک کنترلر از نوع ActionResult نباشد، به صورت پیش فرض درون یک ContentResult محصور خواهد شد.
5) اگر خروجی متدی در اینجا از نوع void باشد، با ActionResult ایی به نام EmptyResult یکسان خواهد بود. بنابراین با متدهای SendMail و SendMailCompleted به یک نحو رفتار می‌گردد.
6) return Json یاد شده که خروجی‌اش از نوع JsonResultاست در پیاده سازی‌های Ajax ایی کاربرد دارد.
7) جهت بازگرداندن حالت وضعیت 403 یا غیرمجاز می‌توان از return new HttpUnauthorizedResult استفاده کرد.
8) یا جهت اعلام مشکلی در سمت سرور به کمک return new HttpStatusCodeResultکد ویژه‌ای را می‌توان به کاربر نمایش داد.
9) به کمک return RedirectToAction می‌توان به یک کنترلر و متدی خاص در آن، کاربر را هدایت کرد.

و خلاصه اینکه تمام کارهایی را که پیشتر در ASP.NET Web forms ، مستقیما به کمک شیء Response انجام می‌دادید (Response.Write، Response.End، Response.Redirect و غیره)، اینبار به کمک یکی از ActionResult‌های یاد شده انجام دهید تا بتوان بدون نیاز به راه اندازی یک وب سرور، برای متدهای کنترلرها آزمون واحد نوشت. برای مثال:

[TestMethod]
public void TestMethod1()
{
    // Arrange
    var controller = new ActionResultsController();

    // Act
    var result = controller.Index() as ContentResult;

    // Assert
    Assert.NotNull(result);
    Assert.AreEqual( "Hello, World", result.Content);
}



اشتراک‌ها
20 مقاله و مصاحبه جذاب درباره SaaS در سال 2015

2015 has been a monumental year for Cloud Technology and SaaS in particular. So much has happened, and so much has been discussed, and capturing the very best was not an easy task. Still, I managed to gather what I believe are the top 20 of 2015, from mistakes every SaaS vendor needs to avoid, to insights about the future of Microsoft.  

20 مقاله و مصاحبه جذاب درباره SaaS در سال 2015
اشتراک‌ها
آیا می‌توان از قابلیت‌های C#6 در نگارش‌های پایین‌تر دات نت فریم ورک استفاده کرد؟
 پاسخ: بله! فقط async در نگارش‌های قبل از دات نت 4.5 وجود ندارند و متدهای الحاقی از دات نت 3 به بعد اضافه شدند و نیاز به افزودن ارجاعی به System.Runtime.CompilerServices.ExtensionAttribute دارند (برای دات نت 2 البته).
بنابراین اگر از VS 2015 استفاده می‌کنید برای مثال به سادگی می‌توانید از قابلیت‌های C# 6 در برنامه‌های دات نت 4 استفاده کنید. برای نمونه یک چنین کدی در VS 2015 با دات نت 4 هم قابل کامپایل است و بدون مشکل کار می‌کند:
using static System.Console;

namespace VS2015_Net4_Tests
{
    class Program
    {
        static void Main(string[] args)
        {
            var test = "Test";
            WriteLine($"{test}");
        }
    }
}
آیا می‌توان از قابلیت‌های C#6 در نگارش‌های پایین‌تر دات نت فریم ورک استفاده کرد؟
مطالب
مقدمه ای بر Docker، قسمت پنجم
  در قسمت‌های قبل با کلیات مفاهیم داکر آشنا شدیم. اما بنا داریم در این قسمت با اصول اولیه‌ی تهیه‌ی docker-compose آشنا شده و دستورالعمل اجرای کانتینر‌های مختلف را درون یک فایل نوشته و مدیریت نماییم. در واقع، compose ابزاری است برای تعریف و اجرای اپلیکیشن‌های multi-container.
با استفاده از YAML، دستورالعمل‌های سرویس‌های مختلف را نوشته و با یک دستور همه‌ی آنها را با هم اجرا مینماییم. از compose در تمامی مراحل production, staging, development, testing و همچنین CI workflow استفاده میشود.

برای استفاده از compose سه عمل زیر باید انجام شود:
1- ساخت  و تعریف dockerfile برای هر سرویس.
2- ساخت و تعریف docker-compose.yml. بنابراین هر سرویس میتواند در محیط ایزوله‌ی خود اجرا شود.
3- اجرای دستور docker-compose up.

در قسمت‌های قبلی مراحل ساخت و اجرای image‌ها درون کانتینر و همچنین متصل کردن آن‌ها را به شبکه، بررسی کرده ایم؛ اما در این قسمت میخواهیم با استفاده از docker-compose مدیریت build و اجرای همه‌ی image‌ها را بر عهده بگیریم.
عملا با این ساختار، قابلیت ایجاد شبکه، volume و غیره را خواهیم داشت. بنابراین با استفاده از این config توانایی توزیع برنامه را فقط با یک فایل YAML، خواهیم داشت.


ایجاد پروژه:

فرض کنید نرم افزار ما از دو سرویس Nodejsی همچنین یک دیتابیس Mongo تشکیل شده است. در نهایت باید به چیزی شبیه به تصویر زیر برسیم:


دایرکتوری root این پروژه از دو پوشه به نام‌های nodeapp1 و nodeapp2 تشکیل شده است که داخل هر کدام یک فایل index.js و همچنین package.json و dockerfile وجود دارد؛ همانند مطالب پیشین.
اما چیزی که اینجا اضافه شده است، فایل docker-compose.yml جهت مدیریت و اجرای این برنامه میباشد که حاوی ساختار زیر است:
version: '3'
networks:
  shared-network:
services:
  nodeapp1:
    image: nodeapp1
    build:
      context: nodeapp1
      dockerfile: dockerfile
    ports:
     - "8181:80"
    networks:
     - shared-network
  nodeapp2:
    image: nodeapp2
    build:
      context: nodeapp2
      dockerfile: dockerfile
    ports:
     - "8182:80"
    networks:
     - shared-network
  mongo:
    image: mongo
    ports:
      - "27017:27017"
    networks:
      - shared-network
1) ابتدا یک شبکه از نوع bridge را به نام shared-network میسازیم.
2) برای مشخص کردن سرویس‌های این برنامه از services استفاده کرده و آن‌ها را تعریف مینماییم.
3) سرویس nodeapp1 که قرار است تصویری به نام nodeapp1 را ایجاد کند (هدف آن build کردن اولین سرویس میباشد. همانطور که مشخص است context برنامه، اسم پوشه‌ی nodeapp1 درون ریشه‌ی پروژه است. ضمن اینکه نام dockerfile را هم درون آن پوشه بدان اضافه کرده‌ایم).
4) پورت 8181 را بر روی پورت 80 درون این کانتینر هدایت می‌کنیم.
5) این سرویس، درون شبکه‌ی ایجاد شده‌ی shared-network قرار می‌گیرد.
5) سرویس nodeapp2 را هم به همین شکل اضافه می‌کنیم.
6) سرویس mongo قرار نیست هیچ کدی را build کند و هدف، فقط اجرای mongo درون شبکه‌ی shared-network است که بقیه سرویس‌ها بتوانند بدان وصل شوند.


برای ساخت و اجرا نیز در ریشه‌ی این پروژه، ترمینال خود را باز کرده و دستورات زیر را وارد مینماییم:
برای build کردن:
 docker-compose build
برای اجرا کردن:
 docker-compose up
برای حذف کردن:
 docker-compose down
برای stop کردن موقتی:
 docker-compose stop
برای start کردن مجدد:
 docker-compose start

و اگر بخواهیم بعد از build کردن، بصورت خودکار نیز اجرا شود، از دستور زیر استفاده میکنیم:
 docker-compose run --build

dockerfile هر دو سرویس نیز بصورت ساده همانند مطالب پیشین در نظر گرفته شده‌است:
FROM node
COPY . /var/www
WORKDIR /var/www
RUN npm i
EXPOSE 80
ENTRYPOINT node index

در صورتیکه بخواهیم نگاهی هم به کد‌های نوشته شده بیندازیم، نکته‌ی جالبی مد نظر قرار میگیرد؛ بطور مثال از آنجائیکه همه‌ی کانتینر‌های اجرا شده، درون یک شبکه هستند، برای فراخوانی سرویس‌های دیگر کافیست با نامشان صدا زده شوند. بطور مثال در nodeapp1 برای فراخوانی nodeapp2 به راحتی با نام صدا زده شده است و احتیاجی به فراخوانی با ip نیست. کدهای زیر مربوط به فایل index.js در سرویس nodeapp1 میباشند (بدلیل اینکه روی پورت 80 درون کانتینر قرار گرفته‌است، دیگر لازم به وارد نمودن پورت نبودیم؛ در غیر اینصورت بطور مثال باید درخواستی بصورت http://nodeapp2:5000 را ارسال مینمودیم):
const express = require('express');
const fetch = require('node-fetch');
const app = express();

app.get('/', async (req, res) => {
    let response = await fetch("http://nodeapp2/");
    text = await response.text();
    res.send(text);
})

app.listen(80, () => console.log(`listening on port 80!`))
 بعد از اجرا کردن docker-compose، به راحتی سرویس‌های ما از طریق پورت 8181 و 8182 قابلیت فراخوانی را دارند. 

نکته: override کردن compose‌ها نیز قابل انجام است. بدین معنا که شما یک نسخه برای build و استفاده در محیط development و نسخه‌های دیگری بطور مثال برای production خود تعریف مینمایید؛ مثلا روی پروداکشن، environment variables‌های متفاوتی را در نظر میگیرید. YAML زیر را مشاهده کنید:
 version: '3'

services:
nodeapp1:
  environment:
- PRODUCTION: 'true'
nodeapp2:
  environment:
- PRODUCTION: 'true'

فرض کنید که قرار است YAML فوق بر روی فایل قبلی، بازنویسی شود؛ با استفاده از دستور زیر:
 docker-compose -f docker-compose.yml -f docker-compose.prod.yml up

تمام کد‌های فوق از اینجا «node.rar» قابل دریافت میباشد.
مطالب
نحوه تهیه گزارش در SSRS و انتشار آن روی وب سرور
یکی از محصولات پرکاربرد و حرفه ای مایکروسافت در زمینه تولید گزارش SQL Server Reporting Services یا به اختصار SSRS می‌باشد . در این پست نحوه ایحاد یک گزارش ساده به صورت والد و فرزندی ، انتشار گزارش روی وب سرور و مدیریت نمایش ستون‌ها با استفاده از Expression‌ها را در محیط BIDS بیان می‌کنم



برای انجام این پروسه ، از ابزار BIDS استفاده خواهیم کرد . همچنین برای اطلاعات و داده‌ها از دیتابیس آزمایشی Adventure works استفاده می‌کنیم (دانلود )

 


صورت مسئله : گزارش از دپارتمان‌های کاری و تعداد کارمندان مرد و زن هر دپارتمان . که با کلیک روی هر سطر گزارش (بسته به جنسیت) بتوان لیست تمام افراد آن دپارتمان را دید .


بخش اول :

برای شروع BIDS را باز کرده و یک پروژه از نوع Report Server Project استارت بزنید .

 
نام این پروژه را در اینجا introductionPrj1 قرار دادم .

همانطور که ملاحظه می‌کنید ، سه پوشه در Solution explorer قرار دارد که برای تعریف پایگاه داده با پوشه Shared Data Sources و برای تعریف گزارشات از پوشه Reports استفاده خواهیم کرد

برای این منظور ابتدا یک data source تعریف می‌کنیم :


و سپس شروع به ساختن یک گزارش می‌کنیم :

مراحل را تا رسیدن به مرحله تعریف Query پی میگیریم .


انتخاب دیتا سورس :


در اینجا می‌خواهیم قسمت اول گزارش یعنی فهرست کردن تعداد کارمندان هر دپارتمان را به تفکیک جنسیت مشاهده کنیم :
SELECT DEPARTMENTNAME, GENDER, COUNT(1) AS COUNT FROM DBO.DIMEMPLOYEE GROUP BY DEPARTMENTNAME,GENDER ORDER BY DEPARTMENTNAME,GENDER

برای مشاهده صحت دستور می‌توانید از Query Builder کمک بگیرید :


ادامه تنظیمات را مانند تصویر پی بگیرید (تعریف Tabular بودن گزارش و طراحی جدول و theme و نام گذاری گزارش )






به این ترتیب بخش اول گزارش ایجاد شد . حال باید زیر گزارش مربوطه را ایجاد کنیم :

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

SELECT EMPLOYEEKEY,FIRSTNAME,LASTNAME, MIDDLENAME,TITLE,HIREDATE, BIRTHDATE,EMAILADDRESS,PHONE,GENDER FROM DBO.DIMEMPLOYEE WHERE DEPARTMENTNAME=@DEPARTMENTNAME AND GENDER=@GENDER

و تست گزارش :

و بقیه قسمت‌ها مانند قبل :



تا به این مرحله data source و گزارش‌ها ایجاد شدند :

اکنون باید ارتباط بین دو گزارش را برقرار کنیم :

گزارش والد را باز کرده و روی ستون COUNT کلیک راست نموده و گزینه Popperties را انتخاب نمایید :

سپس در تب action گزینه Go to Report را انتخاب نموده و گزارش فرزند را انتخاب نمایید .

در انتها هم باید پارامتر‌ها را تعریف کنید . خروجی مانند زیر خواهد بود :

ToolTip از تب General قابل اعمال است .

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




تا به این مرحله گزارش تکمیل شد که البته برای ظاهر آن هم باید فکری کرد که در این پست اشاره ای نمی‌شود .

بخش دوم :

گزارش جاری فقط قابل استفاده از طریق BIDS است و با توجه به محدودیت دسترسی باید آن را در جایی قرار داد تا کاربران بتوانند از آن استفاده کننده . برای این منظور باید تنظیمات SSRS Web Application انجام شود تا بتواند روی سرور عملیاتی قرار گیرد .

در صورتی که تنظیمات SSRS برای قرار گرفتن روی وب سرور انجام نشده باشد و ما بخواهیم گزارش را Deploy کنیم خطا دریافت خواهیم کرد .

پس در ادامه نحوه تنظیم وب سرور را بیان می‌کنم و پس از آن گزارش را روی وب سرور قرار می‌دهیم :
برای این منظور باید برنامه Reporting Services Configuration Manager که در مسیر نصب SQL Server است برویم



پس از اتصال به سرور به تب Report Manager Url بروید :



در این مرحله باید سرور را تنظیم کنید تا بتوانیم پروژه را روی آن Deploy کنیم . از باز بودن پورت اطیمنان حاصل کنید . سپس وب سرویس را تنظیم کنید که هر دو فقط شامل نام Virtual Directory و Credential آن می‌شود . (مگر اینکه تنظیمات خاصی داشته باشید).


در صورت اجرا کردن مسیر URL باید بتوانید صفحه خانگی آن را مشاهده کنید :

که البته هنوز هیچ گزارشی روی آن قرار نگرفته است .سپس به گزارش خود باز می‌گردیم تا تنظیمات سرور را روی BIDS تکمیل کنیم :
برای این منظور روی پروژه کلیک راست کنید و ابتدا روی Properties کلیک کنید .



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



روی OK کلیک کنید و پروژه را Deploy کنید .

اگر به سایت برگردید ، گزارشات را می‌توانید مشاهده کنید





بخش سوم :

در این مرحله می‌خواهیم یکی از ویژگی هایی که در گزارش گیری کاربرد زیادی دارد ، یعنی نمایش ستون‌های دلخواه در گزارش را به کمک SSRS و BIDS به کار ببریم.

برای این منظور به پنجره Report Data مراجعه کرده و روی Parameters کلی راست کرده و گزینه Add Parameter را انتخاب کنید :



فیلد‌ها را مانند زیر پر کنید : (در اینجا می‌خواهیم یک dropdown به کاربر نشان داده شود تا انتخاب کند که ستون نمایش داده شود یا خیر . همچنین مقدار پیشفرض بله است)


گزینه‌های مورد نظر را انتخاب نمایید

و تعیین مقدار پیش فرض


و نتیجه در BIDS :


اکنون باید تغییر مقدار این ستون را بر روی گزارش اعمال کنیم :
برای همین منظور روی ستون BirthDate در حالت Design کلیک راست کرده و گزینه Column Visibility را انتخاب کنید :

سپس باید تنظیم کنیم که در نمایش و عدم نمایش این ستون باید بر اساس یک عبارت یا expression باشد .


عبارت زیر را وارد کنید (به این معنی که اگر مقدار 1 بود نمایش داده شود در غیر این صورت نمایش داده نشود) برای اطلاعات بیشتر در مورد دستورات Expression به اینجا   و اینجا   و اینجا مراجعه کنید

 =iif(Parameters!ShowBirthDate.Value=1,true,false)



اکنون می‌توانید گزارش را deploy کنید و تنظیمات سطوح دسترسی کاربران را انجام دهید

 
نظرات مطالب
Blazor 5x - قسمت دهم - مبانی Blazor - بخش 7 - مسیریابی
بهبود قسمت «ارسال کوئری استرینگ‌ها به کامپوننت‌های مختلف » در Blazor 6x

در Blazor 6x دیگر نیازی نیست تا با استفاده از «HttpUtility.ParseQueryString»، کار پردازش دستی کوئری استرینگ‌های رسیده، صورت گیرد. برای نمونه فرض کنید Url رسیده، چنین شکلی را دارد:
/search?filter=some+stuff&page=3&assignee=User1&assignee=User2
برای دسترسی به مقادیر کوئری استرینگ‌های آدرس فوق، اینبار کافی است به صورت زیر عمل کنیم:
@code {
    [Parameter]
    [SupplyParameterFromQuery]
    public string Filter { get; set; }

    [Parameter]
    [SupplyParameterFromQuery]
    public int? Page { get; set; }

    [Parameter]
    [SupplyParameterFromQuery(Name = "assignee")]
    public string[] Assignees { get; set; }
}
یعنی ذکر دو ویژگی [Parameter, SupplyParameterFromQuery] بر روی یک خاصیت عمومی کامپوننت، آن‌را آماده‌ی دریافت مقادیر کوئری استرینگ‌های متناظری می‌کند. اگر می‌خواهید نام پارامتر، با نام کوئری استرینگ یکی نباشد (حالت پیش‌فرض)، از خاصیت Name این ویژگی می‌توان استفاده کرد.

نکته: در اینجا مقادیری مانند ذیل قابل قبول هستند:
String, bool, DateTime, decimal, double, float, Guid, int, long
و یا حالت Nullable آن‌ها و یا آرایه‌ای آن‌ها.

امکان ساخت Urlهایی به همراه کوئری استرینگ‌ها جهت هدایت ساده‌تر به آن‌ها

به Blazor 6x، متدهای الحاقی UriWithQueryParameter نیز اضافه شده‌اند و کار آن‌ها، افزودن ساده‌تر کوئری‌استرینگ‌ها به Urlها است که نمونه‌ای از آن به صورت زیر است:
var actualUri = NavigationManager.GetUriWithQueryParameters(new Dictionary<string, object>
        {
            ["full name"] = "John Doe", // Single value
            ["ping"] = new int?[] { 35, 16, null, 87, 240 }
        });
که چنین Url ای را تولید می‌کند (نمونه‌ای از روش تعریف کوئری استرینگ‌های آرایه‌ای):
host/?full%20name=John%20Doe&ping=35&ping=16&ping=87&ping=240
مثال‌های بیشتر آن‌را در اینجا می‌توانید مشاهده کنید.
مطالب
استفاده از postgres در برنامه‌های ASP.NET Core - قسمت اول
postgres یک بانک اطلاعاتی متن باز، قدرتمند و relational میباشد که پس از 30 سال توسعه‌ی فعال، به کارآیی بالا، قابل اطمینان بودن و قدرتمند بودن شهرت دارد. همچنین در بنچمارک‌های مربوط به وبسایت techempower نیز استفاده از  این پایگاه داده در کنار asp.net core باعث شده‌است تا جایگاه خوبی کسب شود. علاوه بر این ویژگی‌ها، انعطاف نوع داده‌ها (data type) سبب تفاوت بین رقبا شده است. برای مثال فرض کنید که یک جدول به اسم Blog و قصد ذخیره تگ‌های مقاله را داریم. کار به چه صورت خواهد بود؟
اگر پیش‌تر با postgres آشنایی نداشته باشید، یکی از دو سناریو زیر را پیاده سازی خواهید کرد:
- ذخیره در یک فیلد به صورت nvarchar و جدا کردن حرف‌ها با یک کاراکتر (برای مثال: dntips, csharp با کارکتر , از هم جدا شده اند)
Blog ID
BlogID int
Title nvarchar(250)
Tags nvarchar(500)

- ساخت جدول و رابطه چند به چند 
Blog Tags Tbl
BlogID int
TagID int
ایراد قطعه کد اول عدم امکان سرچ اصولی در بین کلمات کلیدی میباشد؛ زیرا شما مجبور به جستجو در یک فیلد هستید که واژه‌ها با کاراکتری از یکدیگر جدا شده‌اند. پس شما سرچ دقیقی نخواهید داشت. پس از این مشکل میتوان به وجود تگ‌های تکراری در یک رکورد و یا نداشتن تگ‌ها به صورت یکپارچه اشاره کرد و به عنوان مشکل آخر میتواند به یک سربار برای سیستم تبدیل شود. چون هر بار که دیتا واکشی میشود، باید یکبار کلمات را از یکدیگر جدا و سپس به یک آرایه تبدیل و هنگام ذخیره شدن نیز مجددا این رشته‌ها را به هم بچسبانیم.
در مورد کد دوم هم شاید بتوان به انباشته شدن زیاد سطر‌ها و یا عدم ساختار مدرن اشاره کرد.
اما در postgres به راحتی میتوان این گونه دیتا‌ها را به صورت آرایه ذخیره سازی کرد:
CREATE TABLE sal_emp (
    name            text,
    pay_by_quarter  integer[],
    schedule        text[][]
);
که سبب سرچ اصولی و واکشی سریع‌تر اطلاعات خواهد شد.
راجع به نوع داده array در postgres در بیشتر مطالعه کنید.
در همین بحث دیتا تایپ‌ها میتوان به نوع text اشاره کرد که جایگزینی برای nvarchar و یا varchar میباشد. در اینجا نیازی به مشخص کردن سایز رشته نیز نیست و تمام فرآیند، به صورت خودکار در پس‌زمینه انجام خواهد شد.  مثلا بجای nvarcahr 500 و یا MAX تنها، نوع داده را برابر text قرار می‌دهید.
از نظر ساختار زبانی و syntax بسیار شبیه به سایر provider‌‌ها میباشد و تنها تفاوت اساسی آن، حساس بودن به حروف کوچک و بزرگ است.
سایر مزیت‌های postgres را میتوانید از زبان shayro jan sky، در کانال دات نت و در ویدیو لینک شده مشاهده کنید.

مزیت بزرگ آن که باعث میشود تا از آن بتوانیم در پروژه‌های خود استفاده کنیم، سازگاری آن با ef core میباشد. یعنی اگر کل برنامه‌ی شما با ef core پیاده سازی شده باشد، با عوض کردن متد UseSqlServer به UseNpgsql در کلاس program، مشکلی در برنامه رخ نخواهد داد و اپلیکیشن شما بجای استفاده از sql server به راحتی از postgres استفاده خواهد کرد.
متد نام برده شده در پکیج زیر قابل دسترسی میباشد:
Npgsql.EntityFrameworkCore.PostgreSQL

کار‌ها تماما مانند ef و حتی با کتابخانه‌های مربوط به آن انجام خواهد شد و تنها تغییر در کدها، همین متد UseNpgsql میباشد که provider را عوض خواهد کرد. 

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

در یک کلاس همانطور که می‌توانیم متد استاتیک و یا پراپرتی استاتیک داشته باشیم، قادر هستیم فیلدهایی را نیز به صورت استاتیک تعریف نماییم. با نوشتن کلمه‌ی کلیدی Static قبل از فیلد یک کلاس، آن فیلد تبدیل به فیلدی استاتیک شده و از این پس این فیلد، متعلق به اشیاء ساخته شده‌ی از کلاس نیست و تنها از طریق خود کلاس می‌توان به آن دست یافت. اگر فیلد استاتیک به صورت خصوصی (private) تعریف شود، تنها اعضای داخلی آن کلاس می‌توانند به آن دسترسی داشته باشند و آن را تغییر دهند؛ ولی اگر به صورت عمومی‌تری تعریف شود، هر نوعی که بتواند به آن دسترسی داشته باشد، می‌تواند مقدار آن را ببیند و تغییر دهد.

زمانیکه شما یک کلاس با فیلد استاتیک را تعریف می‌کنید باید مراقب ترتیب مقدار دهی آنها نیز باشید. به عنوان مثال کلاس زیر را در نظر بگیرید:
class AttemptController
{
   internal static int Threshold = MaxAttempts - WarningAttempts;
   internal static int MaxAttempts = 5;
   internal static int WarningAttempts = 2;
}
در نگاه اول شاید کد بالا بدون مشکل به نظر برسد؛ یعنی اگر بخواهیم از مقادیر این فیلدهای استاتیک استفاده کنیم، انتظار داریم فیلد MaxAttempts به مقدار 5، فیلد WarningAttempts به مقدار 2 و فیلد Threshold به تفاضل آنها یعنی 3 مقداردهی شده باشند. ولی اگر کد زیر را اجرا کنید خروجی متفاوتی را مشاهده خواهید کرد:
Console.WriteLine("Maximum: {0}", AttemptController.MaxAttempts);
Console.WriteLine("Warning: {0}", AttemptController.WarningAttempts);
Console.WriteLine("Threshold: {0}", AttemptController.Threshold);

/* OUTPUT
Maximum: 5
Warning: 2
Threshold: 0
*/
همانطور که در این خروجی مشاهده می‌کنید، مقدار فیلد Threshold  به صفر مقداردهی شده است؛ در حالیکه ما انتظار عدد 2 را داشتیم.

دلیل این مقدار غیر منتظره را باید در سند مشخصات زبان سی شارپ ( C# Language Specification ) یافت. در سند مشخصات زبان سی شارپ، نحوه‌ی استفاده‌ی از این زبان و دستورات نحوی ( Syntax ) آن به صورت شفافی توضیح داده شده‌اند. این سند بیان می‌کند هیچ فیلد استاتیکی هرگز نباید بدون مقدار باشد؛ یعنی اگر قبل از مقدار دهی یک فیلد استاتیک بخواهیم به مقدار آن دسترسی داشته باشیم، به مقدار اولیه‌ی نوع آن فیلد، مقدار دهی خواهد شد. پس در مثال بالا چون فیلدهای MaxAttempts  و WarningAttempts  از نوع Integer هستند، مقدار پیش‌فرض صفر را خواهند گرفت. همچنین این سند بیان می‌کند که اگر در کلاسی چندین فیلد استاتیک تعریف شوند و آنها در چند سطر جداگانه مقداردهی شوند (همانند کاری که ما در مثال بالا انجام دادیم) بر طبق ترتیبی که عملیات مقداردهی به آنها انجام میگیرد، مقدار خواهند گرفت. یعنی وقتی که فیلد استاتیک Threshold مقدار دهی می‌شود، چون فیلدهای استاتیک MaxAttempts و WarningAttempts هنوز مقداردهی نشده‌اند، مقدار صفر می‌گیرند. پس در نتیجه‌ی فیلد Threshold هم مقدار صفر را می‌گیرد و چون ترتیب مقدار دهی نیز مهم است، مقدار آن  با تغییر مقدار فیلدهای MaxAttempts و WarningAttempts تغیر نکرده و کماکان صفر باقی خواهد ماند و پس از آن در خط‌های بعدی، فیلدهای MaxAttempts  و WarningAttempts مقدار می‌گیرند.

پس برای رفع این مشکل باید ترتیب مقداردهی فیلدها را به گونه‌ای تغییر داد که قبل از استفاده‌ی از آنها، مقدارشان معلوم باشد.
class AttemptController
{
   internal static int MaxAttempts = 5;
   internal static int WarningAttempts = 2;
   internal static int Threshold = MaxAttempts - WarningAttempts;
}
اینبار خروجی زیر حاصل می‌شود:
Maximum: 5
Warning: 2
Threshold: 3

مشکلی که این راه حل دارد این است که کد خوانایی نیست و قابلیت نگهداری خوبی هم ندارد. از آنجایی ما توسعه دهندگان عادت به تغییر کد‌های دیگران را داریم، قابل پیش بینی‌است که یک توسعه دهنده‌ی دیگر، ترتیب نوشتن فیلدهای استاتیک را مثلا به قصد اینکه بخواهد آنها را به ترتیب حروف الفبا مرتب کند، تغییر دهد که اینکار منجر به یک باگ خواهد شد. یک راه حل بهتر این است که مقداردهی آنها را از تعریف‌اشان جدا کرده و عملیات مقداردهی به آنها را در یک سازنده‌ی استاتیک قرار دهیم که در این صورت هم خروجی بالا را خواهیم داشت:
class AttemptController
{
    internal static int MaxAttempts;
    internal static int WarningAttempts;
    internal static int Threshold;
 
    static AttemptController()
    {
        MaxAttempts = 5;
        WarningAttempts = 2;
        Threshold = MaxAttempts - WarningAttempts;
    }
}