نظرات مطالب
Embed کردن SQL Server Express 2008 در یک برنامه
سلام، ببینید من ورژن‌های متعددی که برای دانلود نسخه 2012 قرار داده شده رو به همراه حجمشون پایین نوشتم. به عنوان مبتدی می‌خواستم بدونم چه وقت از کدام یک از اینها استفاده میشه؟
یک حالتی هست که ویژوال استودیو از من می‌خواد نسخه اکسپرس رو نصب کنم، خوب نسخه ای با حجم و امکانات بالا رو نصب می‌کنم. یک حالتی هم هست که بصورت توکار در یک برنامه قرار داده میشه که کاربر نهایی در اجرای برنامه به مشک برنخوره، حالا چطور متوجه بشیم که کدوم نسخه برای کاربر نهایی مناسبه.
تشکر
SQL Server Express with Tools (with LocalDB, Includes the database engine and SQL Server Management Studio Express) 1.4G
SQL Server Management Studio (Tools only) 939MB
SQL Server Express LocalDB (MSI installer) 24MB
SQL Server Express with Advanced Services (contains the database engine, Express Tools, Reporting Services, and Full Text Search) 1.7G
SQL Server Express (Containing only the database engine) 133MB 
نظرات مطالب
بررسی روش آپلود فایل‌ها در ASP.NET Core
خلاصه نکات این مطلب در برنامه‌های ASP.NET Core

ابتدا بسته‌ی نیوگت DNTCommon.Web.Core را نصب کنید:
PM> Install-Package DNTCommon.Web.Core
سپس مثالی از UploadFileExtensions آن‌را در اینجا می‌توانید مشاهده کنید. همچنین قسمت ذخیره سازی فایل آن نیز تبدیل به یک سرویس به نام IUploadFileService شده‌است. 
اشتراک‌ها
ویژگی های جدید Visual Studio 2017 15.8 Preview 3

Microsoft's release notes highlights for Preview 3 include:

  • Visual Studio now offers .NET Framework 4.7.2 development tools to supported platforms with 4.7.2 runtime included.
  • We improved performance during project unload/reload and branch switching.
  • With added support for Azure Functions, you now have a new target host in the Configure Continuous Delivery to Azure dialog.
  • Git and TFS status now updates properly for external file changes in .NET Core projects.
  • We added new productivity features, such as code cleanup, invert-if refactoring, Go to Enclosing Block, Multi-Caret support, and new keyboard profiles.
  • C++ enhancements include Template IntelliSense, convert macro to constexpr lightbulbs, and experimental in-editor code analysis squiggles.
  • You can now use cross-language debugging with Python 3.7.0rc1.
  • Performance Profiling now offers the ability to pause/resume data collection and adds a new .NET Object Allocation Tracking tool.
  • We included improvements for Android incremental builds in the Xamarinsupport for Xcode 9.4.
  •  
ویژگی های جدید Visual Studio 2017 15.8 Preview 3
اشتراک‌ها
پیش‌نمایش نسخه 15.8 Visual Studio 2017
پیش‌نمایش نسخه 15.8 Visual Studio 2017
اشتراک‌ها
معرفی سایت
سایت فوق،یک سایت آموزشی می‌باشد، و در مورد موضوعاتی همچون JAVA،HTML،CSS،CSharp،VB.Net،WPF،Oracle ،PHP ،SQL Serverو بسیاری از زبانهای دیگر، دارای مطالب آموزشی است.
نکته جالب توجه سایت فوق در این است که، مطالبش بصورت خوبی دسته بندی شده است، و مثالهای آن برای یادگیری مفاهیم مختصر و مفید است.
چنانچه برای مشاهده سایت با مشکل مواجه شدید،می بایست از فیلتر شکن استفاده نمایید.
معرفی سایت
مطالب
Blazor 5x - قسمت یازدهم - مبانی Blazor - بخش 8 - کار با جاوا اسکریپت
در حین کار با برنامه‌های وب، چشم‌پوشی از جاوا اسکریپت عملا ممکن نیست؛ هرچند با Blazor، امکان انجام کارهایی را یافته‌ایم که پیشتر با MVC و یا Razor pages میسر نبودند، اما هیچگاه به تنهایی نمی‌تواند جایگزین کامل جاوا اسکریپت، در تولید برنامه‌های وب باشد. بنابراین ضروری است که نحوه‌ی یکپارچگی جاوا اسکریپت را با برنامه‌های مبتنی بر Blazor، بررسی کنیم.


ایجاد کامپوننت جدید BlazorJS

برای بررسی نحوه‌ی تعامل جاوا اسکریپت و Blazor، در ابتدا کامپوننت جدید Pages\LearnBlazor\BlazorJS.razor را ایجاد کرده:
@page "/BlazorJS"

<h3>BlazorJS</h3>

@code
{
}
و همچنین مدخل منوی آن‌را نیز بر اساس مسیریابی ابتدای فایل این کامپوننت، به فایل Shared\NavMenu.razor اضافه می‌کنیم:
<li class="nav-item px-3">
    <NavLink class="nav-link" href="BlazorJS">
        <span class="oi oi-list-rich" aria-hidden="true"></span> BlazorJS
    </NavLink>
</li>


روش فراخوانی کدهای جاوا اسکریپتی از طریق کدهای سی‌شارپ Blazor

فرض کنید می‌خواهیم در حین کلیک بر روی دکمه‌ای مانند دکمه‌ی حذف، ابتدا تائیدیه‌ای را توسط تابع confirm جاوا اسکریپتی، از کاربر اخذ کنیم. روش انجام چنین کاری در برنامه‌های مبتنی بر Blazor به صورت زیر است:
@page "/BlazorJS"

@inject IJSRuntime JsRuntime

<h3>BlazorJS</h3>

<div class="row">
    <button class="btn btn-secondary" @onclick="TestConfirmBox">Test Confirm Button</button>
</div>
<div class="row">
    @if (ConfirmResult)
    {
        <p>Confirmation has been made!</p>
    }
    else
    {
        <p>Confirmation Pending!</p>
    }
</div>

@code {
    string ConfirmMessage = "Are you sure you want to click?";
    bool ConfirmResult;

    async Task TestConfirmBox()
    {
        ConfirmResult = await JsRuntime.InvokeAsync<bool>("confirm", ConfirmMessage);
    }
}
توضیحات:
- در اینجا می‌خواهیم تابع استاندارد confirm جاوا اسکریپتی را از طریق کدهای سی‌شارپ، با کلیک بر روی دکمه‌ی Test Confirm Button، فراخوانی کنیم. به همین جهت onclick@ این دکمه، به متد TestConfirmBox کدهای UI سی‌شارپ این کامپوننت، متصل شده‌است.
- برای دسترسی به توابع جاوا اسکریپتی، نیاز است سرویس توکار IJSRuntime را به کدهای کامپوننت تزریق کنیم که روش انجام آن‌را توسط دایرکتیو inject@ مشاهده می‌کنید. برای دسترسی به این سرویس توکار، نیاز به تنظیمات ابتدایی خاصی نیست و اینکار پیشتر انجام شده‌است.
- سرویس JsRuntime تزریق شده، دو متد مهم InvokeVoidAsync و InvokeAsync را جهت فراخوانی توابع جاوا اسکریپتی به همراه دارد. اگر تابعی، خروجی غیر void داشته باشد، باید از متد InvokeAsync استفاده کرد. برای مثال خروجی تابع استاندارد confirm، از نوع boolean است. بنابراین نوع این خروجی را به صورت یک آرگومان جنریک متد InvokeAsync مشخص کرده‌ایم.
- اولین پارامتر متد InvokeAsync، نام رشته‌ای تابع جاوا اسکریپتی است که قرار است صدا زده شود. پارامترهای اختیاری بعدی که به صورت params object?[]? args تعریف شده‌اند، لیست نامحدود آرگومان‌های ورودی این متد هستند.
- فیلد ConfirmMessage، پیامی را جهت اخذ تائید، تعریف می‌کند که به عنوان پارامتر متد confirm، توسط JsRuntime.InvokeAsync فراخوانی خواهد شد.
- فیلد ConfirmResult، نتیجه‌ی فراخوانی متد confirm جاوا اسکریپتی را به همراه دارد.
- در اینجا روش عکس العمل نشان دادن به خروجی دریافتی از متد جاوااسکریپتی را نیز مشاهده می‌کنید. پس از پایان متد TestConfirmBox که یک متد رویدادگران است، همانطور که در مطلب بررسی «چرخه‌ی حیات کامپوننت‌ها» نیز بررسی کردیم، متد StateHasChanged، در پشت صحنه فراخوانی می‌شود که سبب رندر مجدد UI خواهد شد. بنابراین در حین رندر مجدد UI، بر اساس مقدار جدید ConfirmResult دریافت شده‌ی از کاربر، با تشکیل یک if/else@، می‌توان به نتیجه‌ی تائید یا عدم تائید کاربر، واکنش نشان داد. با این توضیحات در اولین بار نمایش کامپوننت جاری چون مقدار ConfirmResult مساوی false است، پیام زیر را مشاهده می‌کنیم:


اما در ادامه با کلیک بر روی دکمه و تائید پیام ظاهر شده، عبارت زیر ظاهر می‌شود:



روش افزودن یک کتابخانه‌ی خارجی جاوا اسکریپتی به پروژه‌های Blazor

فرض کنید می‌خواهیم پیام‌های برنامه را توسط کتابخانه‌ی معروف جاوا اسکریپتی Toastr نمایش دهیم؛ با این دمو.
مرحله‌ی اول کار با این کتابخانه، دریافت فایل‌های CSS و JS آن است. برای این منظور قصد داریم از برنامه‌ی مدیریت بسته‌های LibMan استفاده کنیم:
dotnet tool install -g Microsoft.Web.LibraryManager.Cli
libman init
libman install bootstrap --provider unpkg --destination wwwroot/lib/bootstrap
libman install jquery --provider unpkg --destination wwwroot/lib/jquery
libman install toastr --provider unpkg --destination wwwroot/lib/toastr
بنابراین خط فرمان را در ریشه‌ی پروژه گشوده و پنج دستور فوق را اجرا می‌کنیم. دستور اول، ابزار خط فرمان LibMan را نصب می‌کند. دستور دوم، یک فایل libman.json خالی را در این پوشه ایجاد می‌کند و سه دستور بعدی، جی‌کوئری، بوت استرپ و toastr را دریافت و در پوشه‌ی wwwroot/lib قرار می‌دهند. Toastr برای اجرا، نیاز به jQuery نیز دارد.
البته تعاریف مداخل آن‌ها به فایل libman.json نیز اضافه می‌شوند. مزیت آن، اجرای دستور libman restore برای بازیابی و نصب مجدد تمام بسته‌های ذکر شده‌ی در فایل libman.json است.

پس از دریافت بسته‌های سمت کلاینت آن، مداخل مرتبط را به فایل Pages\_Host.cshtml برنامه‌ی Blazor Server اضافه خواهیم کرد (و یا در فایل wwwroot/index.html برنامه‌های Blazor WASM).
<head>
    <base href="~/" />
    <link rel="stylesheet" href="lib/toastr/build/toastr.min.css" />

</head>
<body>
 
    <script src="lib/jquery/dist/jquery.min.js"></script>
    <script src="lib/toastr/build/toastr.min.js"></script>
    <script src="_framework/blazor.server.js"></script>
</body>
مدخل فایل css آن‌را در قسمت head و فایل js آن‌را پیش از بسته شدن تگ body تعریف می‌کنیم. در اینجا نیازی به ذکر پوشه‌ی آغازین wwwroot نیست؛ چون base href تعریف شده، به این پوشه اشاره می‌کند.

یک نکته: می‌توان فایل csproj برنامه را به صورت زیر تغییر داد تا کار اجرای دستور libman restore را قبل از build، به صورت خودکار انجام دهد:
<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>

  <Target Name="DebugEnsureLibManEnv" BeforeTargets="BeforeBuild" Condition=" '$(Configuration)' == 'Debug' ">
    <!-- Ensure libman is installed -->
    <Exec Command="libman --version" ContinueOnError="true">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Error Condition="'$(ErrorCode)' != '0'" Text="libman is required to build and run this project. To continue, please run `dotnet tool install -g Microsoft.Web.LibraryManager.Cli`, and then restart your command prompt or IDE." />
    <Message Importance="high" Text="Restoring dependencies using 'libman'. This may take several minutes..." />
    <Exec WorkingDirectory="$(MSBuildProjectDirectory)" Command="libman restore" />
  </Target>
</Project>


روش فراخوانی یک کتابخانه‌ی خارجی جاوا اسکریپتی در پروژه‌های Blazor

پس از افزودن فایل‌های سمت کلاینت toastr و تعریف مداخل آن در فایل Pages\_Host.cshtml برنامه‌ی Blazor Server جاری، اکنون می‌خواهیم از این کتابخانه استفاده کنیم. یک روش کار با این نوع کتابخانه‌های عمومی و سراسری به صورت زیر است:
- ابتدا فایل خالی جدید wwwroot\js\common.js را ایجاد می‌کنیم.
- سپس تابع عمومی و سراسری ShowToastr را بر اساس امکانات کتابخانه‌ی toastr و مستندات آن، به صورت زیر ایجاد می‌کنیم:
window.ShowToastr = (type, message) => {
  // Toastr don't work with Bootstrap 4.2
  toastr.options.toastClass = "toastr"; // https://github.com/CodeSeven/toastr/issues/599

  if (type === "success") {
    toastr.success(message, "Operation Successful", { timeOut: 20000 });
  }
  if (type === "error") {
    toastr.error(message, "Operation Failed", { timeOut: 20000 });
  }
};
چون تابع ShowToastr به شیء window انتساب داده شده‌است، در سراسر برنامه‌ی جاری قابل دسترسی است.
سطر اول آن هم برای رفع عدم تداخل با بوت استرپ 4x اضافه شده‌است. بوت استرپ 4x به همراه کلاس‌های CSS مشابهی است که نیاز است با تنظیم toastClass به مقداری دیگر، این تداخل را برطرف کرد.

- در ادامه مدخل تعریف فایل wwwroot\js\common.js را به انتهای تگ body فایل Pages\_Host.cshtml اضافه می‌کنیم:
    <script src="lib/jquery/dist/jquery.min.js"></script>
    <script src="lib/toastr/build/toastr.min.js"></script>
    <script src="js/common.js"></script>
    <script src="_framework/blazor.server.js"></script>
</body>

در آخر برای آزمایش آن به کامپوننت Pages\LearnBlazor\BlazorJS.razor مراجعه کرده و تابع سراسری ShowToastr را دقیقا مانند روشی که در مورد تابع confirm بکار بردیم، توسط سرویس JsRuntime، فراخوانی می‌کنیم:
@page "/BlazorJS"

@inject IJSRuntime JsRuntime


<div class="row">
    <button class="btn btn-success" @onclick="@(()=>TestSuccess("Success Message"))">Test Toastr Success</button>
    <button class="btn btn-danger" @onclick="@(()=>TestFailure("Error Message"))">Test Toastr Failure</button>
</div>

@code {
    async Task TestSuccess(string message)
    {
        await JsRuntime.InvokeVoidAsync("ShowToastr", "success", message);
    }

    async Task TestFailure(string message)
    {
        await JsRuntime.InvokeVoidAsync("ShowToastr", "error", message);
    }
}
در اینجا دو دکمه، جهت فراخوانی متد ShowToastr با پارامترهای مختلفی تعریف شده‌اند. چون تابع ShowToastr خروجی ندارد، به همین جهت اینبار از متد InvokeVoidAsync استفاده کرده‌ایم. پارامتر اول آن، نام متد ShowToastr است. پارامتر‌های دوم و سوم آن با آرگومان‌های (type, message) تعریف شده‌ی تابع ShowToastr تطابق دارند. به علاوه در این مثال، روش ارسال پارامترها را نیز در onlick@ توسط arrow functions مشاهده می‌کنید.



کاهش کدهای تکراری فراخوانی متدهای جاوا اسکریپتی با تعریف متدهای الحاقی

می‌توان جهت کاهش تکرار کدهای استفاده از تابع ShowToastr، متدهای الحاقی زیر را برای سرویس IJSRuntime تهیه کرد:
using System.Threading.Tasks;
using Microsoft.JSInterop;

namespace BlazorServerSample.Utils
{
    public static class JSRuntimeExtensions
    {
        public static ValueTask ToastrSuccess(this IJSRuntime JSRuntime, string message)
        {
            return JSRuntime.InvokeVoidAsync("ShowToastr", "success", message);
        }

        public static ValueTask ToastrError(this IJSRuntime JSRuntime, string message)
        {
            return JSRuntime.InvokeVoidAsync("ShowToastr", "error", message);
        }
    }
}
و سپس فضای نام آن‌را به فایل Imports.razor_ معرفی نمود تا در تمام کامپوننت‌های برنامه قابل استفاده شوند.
@using BlazorServerSample.Utils
به این ترتیب به فراخوانی‌های ساده شده‌ی زیر خواهیم رسید:
async Task TestSuccess(string message)
{
   //await JsRuntime.InvokeVoidAsync("ShowToastr", "success", message);
   await JsRuntime.ToastrSuccess(message);
}


فراخوانی یک متد عمومی واقع در کامپوننت فرزند از طریق کامپوننت والد

فرض کنید در کامپوننت فرزند Pages\LearnBlazor\LearnBlazor‍Components\ChildComponent.razor که در قسمت‌های قبل آن‌را تکمیل کردیم، متد عمومی زیر تعریف شده‌است:
@inject IJSRuntime JsRuntime


@code {
    // ...

    public async Task TestSuccess(string message)
    {
        await JsRuntime.ToastrSuccess(message);
    }
}
اکنون اگر بخواهیم این متد عمومی را از طریق کامپوننت والد یا دربرگیرنده‌ی آن فراخوانی کنیم، نیاز است از مفهوم جدیدی به نام ref استفاده کرد. برای این منظور به کامپوننت Pages\LearnBlazor\ParentComponent.razor مراجعه کرده و تغییرات زیر را اعمال می‌کنیم:
@page "/ParentComponent"

<ChildComponent
    OnClickBtnMethod="ShowMessage"
    @ref="ChildComp"
    Title="This title is passed as a parameter from the Parent Component">
    <ChildContent>
        A `Render Fragment` from the parent!
    </ChildContent>
    <DangerChildContent>
        A danger content from the parent!
    </DangerChildContent>
</ChildComponent>

<div class="row">
    <button class="btn btn-success" @onclick="@(()=>ChildComp.TestSuccess("Done!"))">Show Alert</button>
</div>


@code {
    ChildComponent ChildComp;
    // ...
}
با استفاده از ref@ که به فیلد ChildComp انتساب داده شده‌است، می‌توان ارجاعی از کامپوننت فرزند را (وهله‌ای از کلاس مرتبط با آن‌را) در کامپوننت جاری بدست آورد و سپس از آن جهت فراخوانی متدهای عمومی کامپوننت فرزند استفاده کرد.


کدهای کامل این مطلب را از اینجا می‌توانید دریافت کنید: Blazor-5x-Part-11.zip
مطالب
آموزش MDX Query - قسمت چهارم –آشنایی با AdventureWorksDW2008R2 و آشنایی با محیط BIMS

در این قسمت تلاش می‌کنم در خصوص محیط BIMS (Business Intelligence Management Studio)  و همچنین AdventureWorksDW2008R2 توضیحاتی را ارائه کنم. در ابتدا در خصوص طراحی انجام شده در Data Warehouse  مربوط به پایگاه داده‌ی Adventure Works 2008 توضیحاتی ارایه می‌گردد.

شاید بهترین کار در خصوص آشنایی با یک پایگاه داده نگاه کردن به دیاگرام کلی آن پایگاه داده باشد. بنابر این در ابتدا می‌بایست یک دیاگرام از پایگاه داده‌ی AdventureWorksDW2008R2 بسازیم (این کار را در SQL Server Management Studio انجام می‌دهیم) . قبل از ساخت دیاگرام می‌بایست کاربر Sa را به عنوان Owner پایگاه داده معرفی کنیم.

برای این منظور ابتدا Properties پایگاه داده‌ی AdventureWorksDW2008R2  را گرفته و به قسمت Files رفته و با انتخاب دکمه‌ی ... در مقابل Owner و جستجوی کاربر Sa ، اقدام به مشخص کردن مالک پایگاه داده می‌کنیم. و سپس دکمه‌ی Ok را می‌زنیم.  

مطابق شکل زیر 


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


با یک نگاه اجمالی مشخص می‌گردد که نام تمامی جداول پایگاه داده‌ی DW یا با کلمه‌ی Dim یا با کلمه‌ی Fact شروع شده‌اند. 

همان طور که در مقاله‌ی شماره‌ی یک نیز عنوان شد، چندین روش طراحی DW وجود دارد :

1. ستاره ای

2. دانه برفی

3. کهکشانی

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

یکی از روش‌های تهیه‌ی DW این می‌باشد که کاربران خبره در هر سیستم، مشخص نمایند چه گزارشاتی مورد نظر آنها می‌باشد. سپس توسط تیم پشتیبانی آن سیستم‌ها، جداول Fact,Dimension  مورد نیاز برای حصول گزارش مربوطه تهیه گردد.

شاید ذکر این نکته جالب باشد که برای توسعه‌ی یک پایگاه داده‌ی Multidimensional توسط Solution ‌های ماکروسافت نیازی به آشنایی با یک محیط کار ( IDE ) جدید نمی‌باشد. همان طور هم که در مقاله‌ی قبلی اشاره شد، برای Deploy کردن یک پایگاه داده‌ی چند بعدی ( Multidimensional ) از خود محیط   Visual Studio .Net استفاده می‌شود. بنابر این آن دسته از برنامه نویسانی که با این محیط آشنا می‌باشند به راحتی می‌توانند به توسعه‌ی پایگاه داده‌ی چند بعدی بپردازند.

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

در ابتدا اجزا BIMS را برای شما توضیح می‌دهم و سپس در خصوص ساخت هر کدام از آنها و ترتیب ساخت آنها توضیحاتی ارایه خواهم داد.

مسیر باز کردن برنامه‌ی  SQL Server Business Intelligence Development Studio = BIDS در زیر آمده است:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft SQL Server 2012\ SQL Server Data Tools

دقت داشته باشید که در صورت استفاده از نسخه‌ی Sql Server 2008 می‌بایست مسیر زیر را جستجو نمایید:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft SQL Server 2008 R2

با نگاه کردن به محیط BIMS  می توانید پنجره‌ی Solution Explorer  را مشاهده کنید .(در صورت عدم مشاهده، می‌توانید این پنجره را از منوی View باز کنید)



در پنجره‌ی Solution Explorer ابتدا نام Solution و در زیر آن، نام پروژه را خواهیم دید (نام پروژه و نام پایگاه داده‌ی چند بعدی، مشابه یکدیگر می‌باشند) و در زیر نام پروژه، موارد زیر را می‌بینیم:

1. Data Source

2. Data Source View

3. Cubes

4. Dimensiones

5. ….

Data Source  : عملا برقرار کننده‌ی پروژه با Data Warehouse می‌باشد. دقت داشته باشید که امکان تهیه یک پایگاه داده‌ی چند بعدی از چندین DW وجود دارد و حتا نوع DW ‌ها می‌تواند متفاوت باشد (به عبارت دیگر ما می‌توانیم چندین DW در RDBMS ‌های متفاوت داشته باشیم و همه‌ی آنها را در یک Multidimensional Database تجمیع کنیم). برای انجام چنین کاری باید چندین Data Source  تعریف کنیم. 


Data Source View : هر Data Source می‌تواند دارای چندین تقسیم بندی با مفاهیم Business ی باشد. برای هر کدام از این دسته بندی‌ها می‌توانیم یک یا چند Data Source View  ایجاد کنیم . به عبارت دیگر ایجاد Data Source View ‌ها سبب خلاصه شدن تعداد جداول Fact , Dimension براساس یک بیزینس خاص می‌باشد و در ادامه راحت‌تر می‌توانیم Cube ‌ها را تولید کنیم. 


نکته: جداول Fact , Dimension در ساختار D ata Warehouse ساخته می‌شوند.

Cubes : محل تعریف Cube ‌ها در این قسمت می‌باشد. در سری آموزش SSAS در خصوص نحوه‌ی ساخت Cube ‌ها شرح کاملی ارایه خواهم کرد. 


Dimensions : با توجه به این که در روال ساخت Cube ما مشخص می‌کنیم چه Dimension هایی داریم، یک سری از Dimension ‌ها به صورت پیش فرض در این قسمت قرار می‌گیرند و البته در صورت تغییر در Data Source View   می‌توانیم یک Dimension را به صورت دستی در این قسمت ایجاد نماییم و سپس آن را به Cube مورد نظر اضافه نماییم. 


دقت داشته باشید که برای ساخت یک پروژه می‌بایست بعد از ساخت Data Warehouse در برنامه‌ی BIMS اقدام به ساخت یک Data Source کنیم و سپس با توجه به Business‌های موجود در سیستم‌های OLTP اقدام به ساخت Data Source View‌های مناسب کرده و در نهایت اقدام به ساخت Cube کنیم. بعد از انجام تنظیمات مختلف در Cube مانند ساخت Hierarchy , KPI و ... نیاز می‌باشد که پروژه را Deploy کنیم تا پایگاه داده‌ی چند بعدی (MDB) ساخته شود. 

در قسمت بعدی نحوه‌ی ساخت یک پروژه در SSAS و چگونگی باز کردن یک پایگاه داده را بررسی خواهیم کرد. 

نظرات مطالب
توسعه برنامه های Cross Platform با Xamarin Forms & Bit Framework - قسمت پنجم
خیلی ممنون. فقط اینه که جواب داد، یعنی اینکه mac اومد بالا، یا اینکه با xamarin هم کار کردید باهاش؟ مزیت روش شما اینه که virtual box توسط docker و genymotion هم استفاده مجدد میشه. و یه سوال دیگه. واقعا سریع‌تر بود مک روی virtual box؟
مطالب
معماری میکروسرویس‌ها
برنامه‌های بزرگ سمت سرور که با تعداد بسیار زیادی کاربر و داده سر و کار دارند، نباید فقط درگیر پاسخگویی سریع و فراهم کردن وب سرویس‌ها برای پلت‌فرم‌های مختلف باشند. این برنامه‌ها باید بتوانند به سادگی رشد کرده، ارتقاء پیدا کنند و به روز شوند. برای ساخت و توسعه این نوع برنامه‌ها، دو مدل معماری وجود دارد: یکی  معماری Monolithic و دیگری معماری Microservices. برای شناخت معماری Microservices، ابتدا بایستی با معماری Monolithic آشنا شد.


 معماری Monolithic چیست؟ 

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


مشکلات معماری Monolithic

  •  در معماری Monolithic زمانیکه ترافیک برنامه در سمت سرور افزایش پیدا میکند، باید برای پاسخگویی، اندازه را افزایش داد. یعنی باید برنامه تحت وب خود را بر روی سرورهای مختلف مجددا اجرا نمود. بخشی به نام Load Balancer، وظیفه توزیع درخواست‌ها را به سرورهای مختلف که بر روی هر یک، یک نسخه از برنامه در حال اجرا است، به عهده دارد. بر اساس توضیحی که از این معماری ارایه شد، در هر یک از این اجرا‌ها، کل برنامه با تمام متعلقاتی که دارد، فارغ از اینکه به همه آنها نیاز است یا نه، از منابع سرور استفاده میکند.

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


معماری Microservices

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

 در دیاگرام بالا میشود اینطور تصور کرد که Service1، یک وب سرور است که با مرورگر برای دریافت درخواست‌ها در ارتباط است و باقی سرویس‌ها حکم API  برای عملیات‌های مختلف را دارند. 


 ارزش معماری Microservices

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


افزایش یک سرویس خاص

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

 در دیاگرام بالا از سرویس یک، دو وهله، در دو سرور جداگانه ایجاد شده است که Load Balancer ترافیک ورودی را بین آنها تقسیم میکند. باقی سرویس‌ها به همان تعداد که بودند باقی می‌مانند.


مشکلات معماری Microservices

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


چه زمانی از معماری Microservices استفاده کنیم؟

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

 

 مدیریت داده‌ها: 

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


پیاده‌سازی معماری Microservices‌ها توسط فریم‌فرک Seneca

Seneca یک فریم ورک Node.js است که برای ساخت برنامه‌های سمت سروری با معماری Microservices و هسته Monolithic استفاده می‌شود. در مطلب بعدی به این فریم‌ورک نگاهی گذرا خواهیم داشت.