مهمان مهمان
نظرات مطالب
Repository ها روی UnitOfWork ایده خوبی نیستند

1- من دقیقا متوجه نشدم منظور شما از decoupling  اول مقاله چیه؟ منظورتون تفکیک Domain از DAL هست؟ اگر اینطوره چه ربطی به UoW  و انواع پیاده سازی اون داره؟
اگر منظورشما انفکاک بین EFContext و Repository هست، توجه شما رو به این نکته جلب میکنم که StudentRepository  که در اول مقاله آورده شده در حقیقت یک پیاده سازی برپایه EF هست به عبارتی EFStudentRepository اسم مناسب‌تری میتونه باشه. بنابراین تزریق Context با هیچ اصلی مغایر نیست. چرا که این Repository یک پیاده سازی خاص از IStudentRepository است.

2- وجود متد Save در Repository؟ نه تنها قابل قبول نیست که اصلا اگر قرار باشه هر Repository مستقلا Save  رو صدا بزنه که مفهوم Transaction از بین میره یا حداقل سخت میشه بهش رسید.

3- با شما موافقم که Generic Repository ایده خوبی نیست. البته فقط تا اینجا موافقم که این الگو برای Expose کردن Interface یک Repository مناسب نیست. چه بسا Repository هایی که فقط SELECT میکنند. ولی اگر پیاده سازی خاصی از یک Repository مد نظر دارید (مثلا پیاده سازی برپایه EF یا NHibernate) اونوقت دقیقا چیزی که به کمک شما میاد همین Generic Repository  برای جلوگیری از کدهای تکراریه.

4- اصولا Repository برای اینکه منطق برنامه (یا به قول شما منطق تجاری) رو پیاده سازی کنه نیست. در حقیقت لایه ای که استفاده کننده مستقیم از Repository است میداند که چه موقع به چه Repository فرمانهای CRUD بده تا منطق برنامه پیاده سازی بشه.

5- در واقع استفاده از امکانات هر ORM تا حد بینهایتی امکان پذیره به شرطی که ORM و توانمندیهاشو در همون لایه DAL محصور کنید مثلا IQueriable  و Cachable و گرنه Leaky Abstraction به طور خزنده و ساکتی کل برنامه رو مثل سرطان در خودش میکشه.

نهایتا اینکه نمیشه یک پیاده سازی مشکل دار از مفهوم Repository + UoW رو بدون درنظر گرفتن مفاهیم مهمی مثل  Service Layer و Domain Model  نقد کرد و بعدا نتیجه گرفت که این الگوها صحیح نیستند. ضمن اینکه این موضوع بسته به تجربه و نظر هر برنامه نویس و معماری میتونه پیاده سازی خاص خودشو داشته باشه که من شخصا هنوز موارد جالب و جدیدی که یک برنامه نویس باهوش برداشت کرده رو میبینم و نتیجه میگیرم که مفهوم Repository + UoW در بین ماها هنوز به یک تعریف جهانشمول نرسیده.

‫۱۰ سال و ۵ ماه قبل، جمعه ۲۶ اردیبهشت ۱۳۹۳، ساعت ۱۷:۲۷
آرمان فرقانی آرمان فرقانی
نظرات مطالب
مفاهیم برنامه نویسی ـ آشنایی با سازنده‌ها
ضمن تشکر از دوستانی که در بحث شرکت کردند و پوزش به دلیل اینکه چند هفته ای در سفر هستم و تهیه مطالب با تأخیر انجام خواهد شد.
برای پاسخ به پرسش دوست گرامی آقای نجف زاده ابتدا بخشی از این مطلب را یادآوری می‌کنم.
"... مساحت را این بار به جای متد به صورت یک پروپرتی پیاده سازی می‌کنیم. اگرچه در آینده بیشتر راجع به چگونگی انتخاب برای پیاده سازی یک عضو کلاس به صورت پروپرتی یا متد بحث خواهیم کرد اما به عنوان یک قانون کلی در نظر داشته باشید عضوی که به صورت منطقی به عنوان داده مطرح است را به صورت پروپرتی پیاده سازی کنید. مانند نام دانشجو. از طرفی اعضایی که دلالت بر انجام عملی دارند را به صورت متد پیاده سازی می‌کنیم. مانند متد تبدیل به نوع داده دیگر. (مثلاً ()Object.ToString) ..."

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

‫۱۱ سال و ۶ ماه قبل، دوشنبه ۳۰ اردیبهشت ۱۳۹۲، ساعت ۲۳:۳۵
علیرضا آرانی علیرضا آرانی
مطالب
الگوریتم های داده کاوی در 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
هدف این سری مقالات که به امید خدا در آینده منتشر خواهد شد، آشنایی با الگوریتم‌های داده کاوی فوق و نحوه مدل کردن مخزن داده توسط این الگوریتم‌ها و در نهایت چگونگی تفسیر مدل های داده کاوی تولید شده، می‌باشد.
‫۷ سال و ۵ ماه قبل، دوشنبه ۱ خرداد ۱۳۹۶، ساعت ۱۵:۳۰
وحید نصیری وحید نصیری
مطالب
بررسی روش دسترسی به HttpContext در ASP.NET Core
در نگارش‌های دیگر ASP.NET، برای دسترسی به اطلاعات درخواست وب جاری، می‌توان از خاصیت استاتیک System.Web.HttpContext.Current استفاده کرد. با حذف شدن System.Web از ASP.NET Core و همچنین بهبود طراحی آن جهت سازگاری کامل با مفاهیم تزریق وابستگی‌ها، دیگر روش استفاده‌ی مستقیم از خواص استاتیک توصیه نشده و بجای آن تزریق اینترفیس ویژه‌ی IHttpContextAccessor توصیه می‌شود.


دسترسی به اطلاعات درخواست وب جاری در ASP.NET Core

برای دسترسی به اطلاعات درخواست جاری در ASP.NET Core، می‌توان از طریق تزریق سرویس جدید IHttpContextAccessor اقدام کرد. این اینترفیس دارای تک خاصیت HttpContext است که به صورت پیش فرض جزو سرویس‌های از پیش ثبت شده‌ی ASP.NET Core نیست و برای اینکه تزریق وابستگی‌ها در اینجا به درستی صورت گیرد، طول عمر این سرویس باید به صورت singleton تنظیم شود:
public void ConfigureServices(IServiceCollection services)
{
   services.AddMvc();
   services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
}
روش کارکرد این سرویس نیز به صورت ذیل است:
- هر زمانیکه درخواست جدیدی برای پردازش فرا می‌رسد، IHttpContextFactory کار ایجاد یک HttpContext جدید را آغاز می‌کند.
- اگر سرویس IHttpContextAccessor پیشتر ثبت شده باشد، IHttpContextFactory کار مقدار دهی HttpContext آن‌را نیز انجام می‌دهد.
- اینجا شاید این سؤال مطرح شود که طول عمر IHttpContextAccessor «باید» به صورت singleton ثبت شود. پس این سرویس چگونه می‌تواند HttpContextهای مختلفی را شامل شود؟ کلاس HttpContextAccessor که پیاده سازی کننده‌ی IHttpContextAccessor است، دارای یک خاصیت AsyncLocal است که از این خاصیت جهت ذخیره سازی اطلاعات Contextهای مختلف استفاده می‌شود. بنابراین کلاس HttpContextAccessor دارای طول عمر singleton است، اما خاصیت AsyncLocal آن دارای طول عمری محدود به یک درخواست (request scoped) می‌باشد.


بنابراین به صورت خلاصه:
- هرجایی که نیاز به اطلاعات HTTP context وجود داشت، از تزریق اینترفیس IHttpContextAccessor استفاده کنید.
- ثبت سرویس IHttpContextAccessor را در ابتدای برنامه فراموش نکنید.
- طول عمر سرویس ثبت شده‌ی IHttpContextAccessor باید singleton باشد.

یک نکته: اگر از ASP.NET Core Identity استفاده می‌کنید، متد services.AddIdentity کار ثبت سرویس IHttpContextAccessor را نیز انجام می‌دهد.



یک مثال: ذخیره سازی اطلاعاتی با طول عمر کوتاه در HttpContext و سپس دسترسی به آن‌ها در کلاس‌های دیگر برنامه

استفاده‌ی از مجموعه‌ی Items شیء HttpContext، یکی از روش‌هایی است که از آن می‌توان جهت ذخیره سازی اطلاعات موقتی و محدود به طول عمر درخواست جاری استفاده کرد. برای مثال در یک کنترلر و اکشن متدی خاص، دو key/value جدید را به آن اضافه می‌کنیم:
public IActionResult ProcessForm()
{
   HttpContext.Items["firstname"] = "Vahid";
   HttpContext.Items["lastname"] = "N.";
   return View();
}
سپس جهت دسترسی به این اطلاعات در یک کلاس دیگر می‌توان به صورت ذیل عمل کرد:
public class MyHelperClass
{
    private readonly IHttpContextAccessor _contextAccessor;
    public MyHelperClass(IHttpContextAccessor  contextAccessor)
    {
        _contextAccessor = contextAccessor;
    }

    public string DoWork()
    {
        string firstName = _contextAccessor.HttpContext.Items["firstname"].ToString();
        string lastName = _contextAccessor.HttpContext.Items["lastname"].ToString();
        return $"Hello {firstName} {lastName}!";
    }
}
در اینجا در کلاسی قرار داریم که مستقیما ارتباطی به کنترلر جاری نداشته و دسترسی مستقیمی به خاصیت HttpContext آن ندارد. بنابراین برای دسترسی به اطلاعات موجود در HttpContext جاری می‌توان سرویس IHttpContextAccessor را به سازنده‌ی این کلاس تزریق کرد و سپس با کمک خاصیت contextAccessor.HttpContext آن، به اطلاعات مدنظر دسترسی یافت.
‫۷ سال و ۱۰ ماه قبل، سه‌شنبه ۱۶ آذر ۱۳۹۵، ساعت ۱۳:۰۵
علی یگانه مقدم علی یگانه مقدم
مطالب
استفاده از کتابخانه جی کوئری در الکترون
از آنجا که الکترون از مفاهیم وب در دسکتاپ به خوبی پشتیبانی می‌کند، پس به راحتی می‌توان از کتابخانه‌های تحت وب و جاوااسکرپیتی چون جی کوئری و آنگولار و ... استفاده کرد. پروژه‌ای داریم که در آن، حین باز شدن صفحه، به کاربر پیام خوش آمد گویی نشان داده می‌شود:
<!DOCTYPE html>
<html>
  <head>

    <script src="./jquery.min.js"></script>
 <meta charset="utf-8">
    <title></title>
    <script>
$(document).ready(()=>
{
   alert("Welcome");
});
    </script>
  </head>
  <body>
  </body>
</html>
برنامه را اجرا می‌کنیم و در کمال تعجب می‌بینیم که پیامی نمایش داده نمی‌شود. برای اینکه بتوانیم اشکال آن را پیدا کنیم بهتر است ابزارهای سودمند توسعه و دیباگینگ کرومیوم را فراخوانی کنیم. برای باز کردن این پنجره، بعد از ایجاد شیء پنجره (فرضا نام متغیر win باشد) عبارت زیر را می‌نویسیم:
  win.openDevTools();
برنامه را بار دیگر اجرا کنید. در سمت راست برنامه یک پنجره جدید باز می‌شود تا بتوانید از طریق آن به دیباگینگ Render Process بپردازید. اگر اینبار به پنجره کنسول نگاهی بیندازید متوجه می‌شوید که خطای داده شده به دلیل عدم شناخت $ بوده است؛ در صورتی که همه چیز به طور صحیح قرار گرفته است و در یک صفحه وب عادی خیلی راحت اجرا می‌شود، پس مشکل از کجاست؟


module و module.exports
در اکثر کتابخانه‌های جاوااسکریپتی شما با عبارت require زیاد مواجه شده‌اید و این امکان از طریق شیءایی به نام module.exports امکان پذیر شده است. شما با کدی مشابه زیر:
exports.sayHelloInEnglish=()=>
{
  console.log("hello");
}
exports.sayHelloInPersian=()=>
{
  console.log('salam');
}
می‌توانید کتابخانه خود را به این شکل در الکترون صدا بزنید:
const test=require("./test.js");
test.sayHelloInPersian();
test.sayHelloInEnglish();
همانطور که می‌بینید شیء module.exports از این طریق می‌تواند در دسترس دیگران قرار بگیرد. حالا جی کوئری و هر کتابخانه مشابهی که کدی شبیه به کد زیر را داشته باشد می‌تواند به چنین مشکلی دچار شود:
if ( typeof module === "object" && typeof module.exports === "object" ) {
  // set jQuery in `module`
} else {
  // set jQuery in `window`
}

کد بالا بررسی می‌کند که آیا  module.export وجود دارد یا خیر. اگر وجود داشته باشد، در اختیار آن قرار می‌گیرد و اگر نداشته باشد در اختیار شیء window قرار می‌گیرد. پس کاری که جی کوئری اینجا انجام می‌دهد این است که توابع آن در اختیار شیء window نیست و در اختیار exports است. به همین علت ما باید شیء جی کوئری را از طریق آن دریافت کنیم. پس کد زیر را قبل از کدهای جی کوئری می‌نویسیم:
<script src="./jquery.min.js"></script>
<script>
window.$=window.jQuery=module.exports;
</script>
یا
window.$ = window.jQuery = require('./jquery.min.js');
حالا دیگر جی کوئری به راحتی اجرا خواهد شد.
‫۸ سال و ۵ ماه قبل، شنبه ۸ خرداد ۱۳۹۵، ساعت ۰۶:۱۰
م محمد شریفی م محمد شریفی
مطالب
Gulp #1
Gulp  ابزاری ست که شما را در انجام دادن کار‌های مختلف توسعه‌ی وب، در سمت Front-end کمک می‌کند و اغلب برای کارهایی هم‌چون موارد ذیل بکار می‌رود:
  • راه اندازی یک وب سرور
  • بارگذاری مجدد مرورگر به صورت خودکار بعد از ذخیره‌ی هر فایل
  • تبدیل پیش پردازنده‌های CSS مانند LESS, SASS به CSS
  • بهینه سازی فایل‌های asset شامل CSS,JS و همچنین عکسها
و در طی این سری آموزشی، همه‌ی آنها را پوشش خواهیم داد.

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

چرا گالپ ؟

ابزار‌های مشابه گالپ، تحت عنوان نام "build tools" یا ابزار‌های ساخت شناخته می‌شوند. دو مورد از معروف‌ترین آنها Gulp و Grunt هستند. اما در سویی دیگر، ابزاری به نام Boroccoli داریم که تمرکزش را بر روی کامپایل فایل‌های asset گذاشته است. تفاوت اصلی بین آنها، چگونگی پیکربندی workflow تان با آن است.


Gulp در مقایسه با گرانت، پیکربندی مختصر و آسان‌تری دارد و سریعتر نیز اجرا می‌شود. اگر می‌خواهید بیشتر در مورد تفاوت Grunt و Gulp بدانید مراجعه کنید به + , + و + .

نصب گالپ

برای نصب گالپ باید NodeJS را بر روی سیستم خود نصب داشته باشید. برای اینکار به سایت  ند جی اس مراجعه کنید و آن را دانلود کرده و نصب کنید. پس از این‌کار حالا در خط فرمان سیستم عامل خود، دستور زیر را برای نصب گالپ وارد کنید :
sudo npm install -g gulp
npm install دستوری است که با استفاده از Node Package Manager یا npm یک پکیج گالپ را از مخزن‌های Node دانلود و بر روی سیستم شما نصب می‌کند. توجه کنید که فقط کاربران مک و لینوکس می‌توانند از sudo استفاده کنند. برای ویندوز باید خط فرمان خود را به صورت Run As Admin باز کنید؛ در غیر این صورت ممکن است در هنگام نصب، با خطا مواجه شوید.
g- یک دستور پرچم است که باعث نصب گالپ به صورت global بر روی سیستم شما می‌شود تا در کل سیستم شما، دستور گالپ در دسترس باشد و نه منحصرا در مسیر نصب کنونی.
بسته به سرعت اینترنت شما، زمانی طول خواهد کشید و در نهایت برای اینکه مطمئن شوید که گالپ بر روی سیستم شما نصب شده‌است، دستور زیر را در خط فرمان وارد کنید:
gulp -v
اگر خروجی مشابه زیر را مشاهده کردید، نصب گالپ با موفقیت انجام شده‌است:
 CLI version 3.9.0
Local version 3.9.0
در قسمت بعدی به ساخت یک پروژه با گالپ خواهیم پرداخت و درک مفاهیم گفته شده در این جلسه را که شاید برایتان گنگ باشد، به صورت عملی کار خواهیم کرد.
‫۹ سال و ۲ ماه قبل، دوشنبه ۱۶ شهریور ۱۳۹۴، ساعت ۱۵:۴۰
ایمان رحیمی نیا ایمان رحیمی نیا
مطالب
معرفی Actor Based Programming و توسعه نرم افزار های مقیاس پذیر و دارای عملیات همزمان بسیار زیاد - قسمت دوم
در  قسمت قبل توضیحاتی راجع به مقدمات Actor Based Programming و کاربرد آن داده شد و چند framework نیز برای توسعه به این روش معرفی گردید. در این قسمت جزئیات بیشتری را از این روش توسعه، ارائه خواهیم داد.
خط تولید کارخانه‌ای را فرض کنید که در آن یک قطعه از ابتدای خط حرکت نموده و کارگران مستقر در خط تولید نیز هر کدام بنا به وظیفه‌ی خود، کاری را بر روی قطعه‌ی مورد نظر انجام می‌دهند؛ به طوریکه در انتهای خط تولید، آن قطعه‌ی اولیه، به یک محصول کامل تبدیل می‌شود.

 ایده‌ی Actor Based نیز هم از همین روش الهام گرفته است. با این تفاوت که بجای کارگران، Thread داریم و بجای قطعه نیز یک پیام یا object و بجای خط تولید نیز خط لوله یا pipeline را داریم. همانطور که در قسمت قبل اشاره کردم، وظیفه‌ی توسعه دهنده در این روش، طراحی یک خط لوله و نوشتن کد مربوط به هر thread است. به همین سادگی!
یعنی تمام پیچیدگی‌های مربوط به concurrency و مسائل فنی توسط یک framework مثل TPL DataFlow یا Akka کنترل و مدیریت می‌شود و توسعه دهنده با تمرکز بر روی مسئله‌ی خود، شروع به طراحی (کانفیگ) خط لوله و نوشتن کد مربوط به هر کدام از thread‌ها می‌نماید.

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

خوب حالا که با مفاهیم خط لوله و اکتور آشنا شدیم، یک مسئله‌ی بسیار ساده را در نظر می‌گیریم و آن را با این روش حل می‌کنیم. فرض کنید یک رشته (string) داریم و می‌خواهیم عملیات زیر را بر روی آن به ترتیب انجام دهیم:

1- فاصله‌های اضافی ابتدا و انتهای رشته حذف شود.

2- اگر رشته یک کلمه‌ای است lowerCase شود.

3- اگر رشته بیش از یک کلمه است، تمام کلمات، به جز کلمه‌ی اول، حذف شوند و سپس مرحله‌ی 2 بر روی آن انجام شود.

4- نتیجه‌ی کار در خروجی نمایش داده شود.

حالا می‌خواهیم انجام هر یک از عملیات فوق را به یک اکتور سپرده و یک خط لوله را برای حل این مسئله طراحی کنیم. در قسمت بعدی به صورت عملی و با TPL DataFlow مایکروسافت این کار را انجام می‌دهیم.

‫۹ سال و ۲ ماه قبل، پنجشنبه ۲۲ مرداد ۱۳۹۴، ساعت ۱۹:۱۵
علی یگانه مقدم علی یگانه مقدم
مطالب
آشنایی با CLR: قسمت سوم
در اینجا ما زیاد بر روی جزئیات یک اسمبلی مانور نمی‌دهیم و آن را به آینده موکول می‌کنیم و فقط مقداری از مباحث اصلی را ذکر می‌کنیم.

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

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

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

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

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

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

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

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

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

1:data pages اساسی‌ترین واحد نگهداری داده در اس کیوال سرور، صفحه نام دارد. فضای دیسک اختصاص یافته به فایل داده بانک، برای یک بانک اطلاعاتی به صورت منطقی به صفحات پیوسته از صفر تا n تقسیم بندی می‌شود. همچنین لازم به ذکر است عملیات خواندن و یا نوشتن در دیسک، در سطح این صفحه‌ها صورت می‌گیرد که در تصویر زیر قابل مشاهده است:


 لازم به ذکر است در sql server هر صفحه، 8 کیلوبایت است. این مورد به این معنی است که هر بانک اطلاعاتی، دارای 128 صفحه به ازای هر یک مگابایت است. هر صفحه دارای 96 بایت با عنوان header یا سرصفحه است که شامل اطلاعات سیستمی در مورد صفحه است. این اطلاعات سیستمی شامل مواردی چون page number یا شماره صفحه و نوع صفحه یا page type و مقدار فضای خالی آن صفحه و شماره شناسایی یک واحد اختصاص یافته یا به اختصار allocation unit id و.... هستند می‌باشد. نکته جالب و قابل توجه این است که فایل‌های ثبت وقایع یا Log files از صفحه استفاده نمی‌کنند؛ بلکه شامل یکسری رکورد log هستند.
 برای بدست آوردن اطلاعات در مورد فایلهای دیتابیس می‌توانید از کد زیر استفاده نمایید SELECT * FROM sys.database_files که خروجی زیر را به شما نشان می‌دهد:


 extents: به ابتدایی‌ترین قسمتی که sql server امکان مدیریت بر آن را دارد extent گویند. هر extent شامل 8 صفحه‌ی به هم پیوسته است. لازم به ذکر است که sql server هر 1 مگابایت را به شانزده extent اختصاص می‌دهد. sql server شامل دونوع extent است که عبارتند از : uniform,mixed uniform extent متعلق به یک شیء است و هر هشت صفحه‌ی آن فقط توسط یک شیء قابل استفاده‌است. mixed extent می‌تواند حداکثر بین هشت شیء به اشتراک گذاشته شود؛ به نحوی که هر یک از هشت صفحه می‌توانند متعلق به یک شیء باشند. همانطور که در شکل زیر می‌بینید به طور پیش فرض با ایجاد یک جدول، یک mixed extent به آن اختصاص داده می‌شود. در صورتیکه این شیء به اندازه‌ی هشت صفحه رشد کند، به آن یک uniform extent اختصاص داده میشود.


فایلهای بانک اطلاعاتی
هر بانک اطلاعاتی در sql server دارای سه نوع فایل است
فایلهای داده اولیه یا به اختصار primary data files
فایلهای داده‌های ثانویه یا به اختصار secondary data files
فایلهای ثبت وقایع یا به اختصار log file
فایل ثبت وقایع برای نگهداری و ثبت وقایع که برای عملیات recovery مورد نیاز است. معمولا یک بانک اطلاعاتی یک log file دارد؛ ولی می‌تواند بیشتر هم داشته باشد. پسوند این نوع فایلها ldf است .

‫۹ سال و ۷ ماه قبل، جمعه ۲۹ اسفند ۱۳۹۳، ساعت ۲۳:۵۰
مسعود پاکدل مسعود پاکدل
مطالب
ارتباط بین Controller و Directive در AngularJs
در پست قبلی با کلیات مفاهیم دیرکتیو‌ها آشنا شدید. در این پست قصد داریم برخی توابع  کنترلرهای تعریف شده در Angular را به وسیله دیرکتیو‌های تعریف شده در ماژول فراخوانی نماییم. در ادامه این موضوع را طی یک مثال بررسی خواهیم کرد.
ابتدا View مورد نظر را به صور زیر ایجاد می‌کنیم:
<script type="text/javascript" src="~/scripts/Modules/module4.js"></script>

<div ng-app="myApp">
    <div ng-controller="myCtrl">
        <span enter>Load More Books</span>
    </div>
</div>
برنامه به این صورت است که با ورود نشانگر ماوس بر روی تگ span (فراخوانی رویداد mouseenter برای تگ هایی که دارای دیرکتیو enter باشند) یک تابع به نام loadMoreBook در کنترلر myCtrl فراخوانی می‌شود.
بک فایل جاوااسکریپتی به نام myModule بسازید و ماژول مورد نظر را ایجاد نمایید:
var app = angular.module('myApp', []);
کنترلر مورد نظر به همراه تابع loadMoreBook را به صورت زیر ایجاد می‌کنیم(البته در اینجا به جای لود واقعی داده از یک alert استفاده کردم):
app.controller('myCtrl', function ($scope) {
    $scope.loadMoreBook = function () {
        alert('Loading Books...');
    }
});
حال نوبت به دیرکتیو مورد بحث می‌رسد که به صورت زیر ایجاد می‌شود:
app.directive('enter', function () {
    return function (scope, element) {
        element.bind('mouseenter', function () {
            scope.loadMoreBook();
        })        
    }
});
اولین نکته این است که به در تابع سازنده دیرکتیو به جای برگشت آبجک مورد نظر یک تابع برگشت داه می‌شود. برای اینکه بتوان به توابع کنترلر محصور کننده دیرکتیو دسترسی داشت آرگومان اول تابع معادل scope مورد استفاده در کنترلر خواهد بود. آرگومان دوم معادل المانی است که  دارای دیرکتیو enter است. در این تابع ابتدا برای رویداد mouseenter رویدادگردان آن پیاده سازی شده است که در آن تابع loadMoreBook کنترلر مورد نظر فراخوانی می‌شود.
خروجی


حال فرض بر این است که در کنترلر بالا تابع دیگری به نام loadMoreAuthor برای فراخوانی نویسندگان نیز وجود دارد. به صورت زیر:
app.controller('myCtrl', function ($scope) {
    $scope.loadMoreBook = function () {
        alert('Loading Books...');
    }

    $scope.loadMoreAuthor = function () {
        alert('Loading Authors...');
    }
});
اما برای انعطاف پذیری بیشتر برنامه، قصد داریم دیرکتیو بالا را به گونه ای تغییر دهیم که نام تابع مورد نظر در کنترلر را به عنوان مقدار یک ویژگی دریافت کند. به صورت زیر:

<script type="text/javascript" src="~/scripts/Modules/module4.js"></script>

<div ng-app="myApp">
    <div ng-controller="myCtrl">
        <span enter="loadMoreBook()">Load More Book</span>         
        <hr>
       <span enter="loadMoreAuthor()">Load More Author</span>
    </div>
</div>
برای به دست آوردن مقدار دیرکتیوی که به عنوان ویژگی در المان تعیین شده، باید از آرگومان سوم در تابع سازنده دیرکتیو به صورت زیر استفاده کرد.
app.directive('enter', function () {
    return function (scope, element , attrs) {
        element.bind('mouseenter', function () {
            scope.$apply(attrs.enter);
        })        
    }   
});
در  کد‌های بالا، برای اینکه بتوان بر اساس نام یک تابع آن را فراخوانی کرد، از سرویس apply$ که به صورت توکار در angular تعبیه شده است استفاده کردم. برای به دست آوردن نام تابع، باید از آرگومان سوم تابع (attrs) به همراه نام دیرکتیو استفاده کرد. به دلیل اینکه نام دیرکتیو enter است باید پارامتر سرویس apply$ به صورت attrs.enter باشد. خروجی نیز مانند حالت قبل خواهد بود.
‫۱۰ سال و ۱۱ ماه قبل، پنجشنبه ۲۱ آذر ۱۳۹۲، ساعت ۱۳:۳۵