SQL is unusual is that data is not passively stored. Instead you use declarative SQL to specify the rules that underlie the data and its integrity. When used properly, constraints can avoid having to provide a lot of logic elsewhere. CHECK() and DEFAULT can do a lot to ensure that your data is correct
کتاب Cryptography in .NET Succinctly
Irresponsible ownership of data is the cause of many leaked emails,
data, and other damaging information. Securing a user’s personal
information is the job of software developers. If you, as a developer,
can decrypt the information stored in the database of the system you are
working on, then so can anyone else. In Cryptography in .NET Succinctly,
Dirk Strauss will take readers through generating cryptographic
signatures, hashing and salting passwords, and when and how to use
symmetric vs. asymmetric encryption.
There's two ways to deploy a .NET Core application. There's FDD and SCD. Since TLAs (three letter acronyms) are stupid, that's Framework-dependent and Self-contained. When .NET Core is installed it ends up in C:\program files\dotnet on Windows, for example. In the "Shared" folder there's a bunch of .NET stuff that is, well, shared. There may be multiple folders, as you can see in my folder below. You can have many and multiple installs of .NET Core.
- اخیرا یک نسخهی سبکتر از Kendo UI با مجوز BSD ارائه شده که Grid آنرا ندارد (به عمد).
بنابراین از این لحاظ، مجوز jqGrid بهتر است. مجوز عمومی آن MIT است و در هر نوع پروژهای قابل استفادهاست. مجوز تجاری هم دارد برای حالتیکه بخواهید کامپوننتهای ASP.NET آنرا بخرید که ... نیازی نیست (^ و ^).
3. Can be used in proprietary works The license policy allow you to use this piece of code even inside commercial (not open source) projects. So you can use this software without giving away your own (precious?) source code.
سایر مسایل خارج از بحث جاری است.
در طی این چند سالی که کارم برنامه نویسی ASP.Net بوده است، هیچ نرم افزار پایهای همانند Exchange server در کیفیت کارهای من تاثیر نداشته است و اساسا تمام هماهنگیهای برنامههای من با کمک Exchange server و Outlook صورت میگیرد. از گرفتن تائید تا آلارم فلان درخواست تا یک سری از گزارشات زمانبندی شده و غیره. دیگر کار به جایی رسیده است که اگر کاربران ایمیلی را دریافت نکنند اطلاعات وارد شده در برنامهها را معتبر نمیدانند و به برنامهها مراجعه نمیکنند!
به همین منظور کتابچهی راهنمای نصب و راه اندازی Exchange server 2010 را تهیه کردهام که در طی حدودا 120 صفحه، به صورت کاربردی و ساده، آنچه را که باید برای راه اندازی و مدیریت این برنامه در یک سازمان بدانید، در اختیار شما قرار میدهد.
مقدمهی کتابچه
برنامهی Exchanger server ، نرم افزار ارسال و دریافت ایمیل سازمانی مایکروسافت است که در ردهی محصولات سرور آن شرکت قرار میگیرد. اولین نگارش Exchanger server در سال 1993 ارائه شد و به صورت محدود در اختیار حدود 500 شرکت قرار گرفت. در سال 1996 اولین نگارش عمومی آن به نام Exchange server 4.0 به عموم ارائه گشت و در سال 1997 با ارائهی Exchange server 5.0 آمار مشتریان این محصول به 32 هزار کاربر رسید. به همراه این نگارش، اولین نسخهی برنامه Outlook web access نیز ارائه گردید. با افزایش استقبال از این محصول، در همان سال نگارش 5.5 آن نیز ارائه شد و ظرفیت بانکهای اطلاعاتی آن تا 16TB در نگارش سازمانی آن افزایش یافت. در سال 2000، اولین نگارش یکپارچهی آن با Active directory ارائه شد. بزرگترین مشکل این محصول در سال 2000، کوچ از نگارشهای قدیمی به نگارش جدید بودند که این مشکل در سال 2003 با ارائه Exchange server 2003 برطرف گردید. در اواخر سال 2006 ، Exchange server 2007 ارائه گشت که مهمترین تفاوت آن با نگارشهای قبلی، ارائهی آن تنها برای سکوهای 64 بیتی بود به همراه بهبودهایی در اندازهی صندوقهای پستی تا 2 گیگابایت، تضمین فعالیت بیوقفه بهبود یافته ، شروع به کنار گذاری Public folders و تمهیداتی جهت ارسال و دریافت پیغامهای صوتی. در اواخر سال 2009 نگارش 2010 این محصول ارائه گشت که تنها با ویندوز سرور 2008 سازگار میباشد و در آن عمدهی مشکلات به همراه نگارش 2007 آن برطرف شده است همانند Outlook web access سازگار با تمامی مرورگرهای امروزی، امکان مدیریت تحت وب صندوقهای پستی کاربران، بازنگری در گزینههای تضمین فعالیت بیوقفه و ساده سازی آنها، افزایش تعداد بانکهای اطلاعاتی قابل تعریف در یک سرور و بسیاری از موارد دیگر که در طی چندین فصل به بررسی آنها خواهیم پرداخت.
لینک دریافت: exchange2010.v1.rar
در این بخش ما 4 هدف اصلی را که باید در سیستمهای توزیع شده برآورده شوند، بر اساس ارزش آنها مورد بررسی قرار میدهیم. یک سیستم توزیع شده باید اولا منابع را به آسانی در دسترس کاربران قرار دهد. دوما شفاف باشد و تمام پیچیدگیهای یک سیستم توزیع شده را از دید کاربر، مخفی کند. سوما باز و قابل گسترش باشد؛ بصورتیکه به آسانی و با شفافیت کامل بتوانیم اجزای جدیدی را به آن اضافه کنیم. چهارما مقیاس پذیر باشد؛ بصورتیکه بدون اینکه مشکلی برای سیستم بوجود بیاید، بتوانیم منابع موجود سیستم را افزایش دهیم. در این بخش جزئیات هر یک از این اهداف را مورد بررسی قرار میدهیم.
اهداف سیستمهای توزیع شده
1- Connecting resources and users: مشخصترین و اصلیترین هدف سیستمهای توزیع شده، اتصال کاربران به منابع و اشتراک منابع بصورت کنترل شده با کارآیی بالا برای کاربران است. بهصورتیکه کاربران به آسانی به منابع دسترسی داشته باشند. منظور از منابع، هرچیزی در سیستمهای توزیع شده میتواند باشد. منابعی مانند دادهها، سختافزارها، فایلها، Componentها، زیرسیستمها و هر چیز دیگری که کاربران میتوانند بصورت مستقیم و غیر مستقیم به آنها دسترسی داشته باشند. یکی از مهمترین دلایل دسترسی به این هدف، مسائل اقتصادی است. بطور مثال ممکن است ما سیستم خودمان را طوری طراحی کنیم که پردازشهای بسیار مهم و پیچیده در تعدادی از سخت افزارهای بسیار پر هزینه انجام شوند. به این صورت ما این سخت افزارها را برای سایر قسمتهای سیستم، به اشتراک میگزاریم و از طریق دیگر قسمتهای سیستم، دسترسی آن را به کاربران میدهیم. در این حالت دیگر نیازی نیست هر قسمت جداگانه در سیستم، سخت افزاری بسیار قوی را برای خودش نیاز داشته باشد. یا زمانیکه ما یک زیرسیستم را یکبار پیاده سازی میکنیم و دسترسی آن را به سایر قسمتها میدهیم، سایر سیستمها، دیگر نیازی نیست آن زیرسیستم را برای خودشان پیاده سازی کنند و تنها از زیرسیستم موجود استفاده میکنند. دسترسی به این هدف باعث میشود تا کاربران به راحتی به تمام منابع موجود در سیستمهای توزیع شده دسترسی داشته باشند.
2- Distribution transparency: بدلیل پیچیدگیهای بسیار زیاد در سیستمهای توزیع شده، شفافیت، کمک بسیار بزرگی به سادگی نحوه تعامل کاربر با سیستمهای توزیع شده میکند. شفافیت در سیستمهای توزیع شده بدین معنا است که سیستم باید تمام پیچیدگیهای خود را از دید کاربر مخفی کند و پیاده سازی سیستم بصورت توزیع شده نباید هیچ پیچیدگی را در نحوه تعامل کاربر با سیستم بوجود بیاورد.
درواقع در سیستمهای توزیع شده، درخواست دریافت شده، در بین منابع سیستم توزیع میشود. تمام منابع با همکاری که با یکدیگر انجام میدهند، درخواست مورد نظر را پردازش کرده و پاسخ لازم را به کاربر ارائه میدهند. در این بین ممکن است منابع موجود در سیستم، رفتارهای متفاوتی را داشته باشند؛ مثلا هر زیرسیستم در سخت افزار و سیستم عامل جداگانهای اجرا شود که باعث میشود حتی نحوه دستیابی به فایلها یا دادههای هر زیرسیستم نیز با سایر زیرسیستمها متفاوت باشد. شفافیت در سیستمهای توزیع شده بدین معنا است که یک سیستم توزیع شده باید خود را بهصورت یک سیستم واحد که در یک سخت افزار ارائه میشود، ارائه دهد تا کاربران هیچ نگرانی در نحوه تعامل با سیستم نداشته باشند. شفافیت در سیستمهای توزیع شده جنبههای مختلفی دارد که در این قسمت آنها را بررسی میکنیم.
جنبههای مختلف شفافیت در سیستمهای توزیع شده
1- Access Transparency: شفافیت در دسترسی به منابع یا مخفی کردن پیچیدگیها و روشهای مختلف دسترسی به منابع. زیر سیستمهای متفاوت ممکن است در سیستم عاملهای متفاوتی نیز اجرا شوند و همانطور که میدانید هر سیستم عامل ممکن است نحوه دسترسی به منابعش با سایر سیستم عاملها متفاوت باشد. در اینجا ما باید زیر سیستمهای خود را طوری طراحی کنیم تا این تفاوتهای در نحوه دسترسی به منابع را از دید کاربر مخفی کنند و این حس را به کاربر بدهد که سیستم، یک روش واحدی را برای دسترسی به منابع دارد.
2- Location Transparency: شفافیت در مکان منابع و مخفی کردن اینکه منابع در سطح شبکه توزیع شدهاند. این جنبه بیان میکند که کاربران نمیتوانند بگویند که منابع بصورت فیزیکی در سخت افزارهای متفاوتی توزیع شدهاند.کاربران هیچ درکی از اینکه ممکن است منابع حتی بصورت جغرافیایی در مکانهای بسیار دوری از یکدیگر قرار گرفتهاند، ندارند.
3- Migration Transparency: مخفی کردن اینکه ممکن است مکان منابع تغییر یابند. در یک سیستم توزیع شده ممکن است به هر دلیلی، مکان منابع تغییر کند. بطور مثال ممکن است با افزایش دادهها نیاز به افزودن Node جدیدی به سیستم باشد تا قسمتی از دادههای سیستم از این پس از طریق این Node در دسترس باشند. این جابجایی منابع نباید هیچ تاثیری در نحوهی تعامل کاربر داشته باشد.
4- Relocation Transparency: مخفی کردن اینکه منابع ممکن است در زمان استفاده، تغییر مکان دهند. در این حالت دقیقا در زمانیکه شخص در حال استفاده از منابع است ممکن است منابع جابجا شوند که این جابجایی در زمان استفاده از منابع نباید هیچ تاثیری در نحوه تعامل کاربر با سیستم داشته باشد. بطور مثال زمانیکه دو کاربر از طریق تلفن همراه در حال ارسال اطلاعات برای یکدیگر هستند، جابجایی هر یک از این دو کاربر، نباید تاثیری در جریان ارتباطی آنها داشته باشد.
5- Replication Transparency: مخفی کردن اینکه منابع در چند جا کپی شدهاند. در یک سیستم توزیع شده برای بهبود کارآیی و دسترسی ممکن است منابع در چند جای مختلف کپی شوند و شفافیت در Replication میگوید ما باید این واقعیت را که ممکن است منابع ما در سخت افزارهای مختلفی کپی شده باشند، از دید کاربر مخفی کنیم.
6- Concurrency Transparency: مخفی کردن اینکه ممکن است منابع، بین چند کاربر مشترک باشند. بدلیل بالا بودن تعداد کاربران در سیستمهای توزیع شده، همزمانی در دسترسی به منابع مشترک، بسیار بیشتر اتفاق میافتد و این مهم است که هیچ یک از کاربران ندانند که کاربر دیگری بصورت همزمان در حال استفاده از آن داده است.
7- Failure Transparency: مخفی کردن خرابی و بازیابی منابع یک سیستم توزیع شده، از کاربر. در یک سیستم توزیع شده ممکن است منابع به هر دلیلی از دسترس خارج شوند. در این صورت نباید از دسترس خارج شدن منابع و بازیابی آنها هیچ تاثیری در جریان تعامل کاربر با سیستم داشته باشد.
البته این نکته را نیز بگویم اگرچه شفافیت یکی از اهداف بسیار مهم سیستمهای توزیع شدهاست و ما نیز باید سیستمی را طراحی کنیم که تا حد امکان به این هدف دست پیدا کند، اما بدلیل این که گاهی ممکن است شفافیت تاثیر مخربی بر روی کاربر داشته باشد، باید درجههایی را برای آن در نظر بگیریم. بطور مثال زمانیکه دو کاربر از طریق تلفن همراه خود با یکدیگر در ارتباطند، نیازی به مخفی کردن موقعیت مکانی آنها نیست. یا در سیستمهای موقعیت یاب، اصل بر این است که موقعیت منابع مختلف مشخص باشند. یا زمانیکه قرار است یک درخواست را برای یک چاپگر ارسال کنیم بهتر است درخواست ما به نزدیکترین چاپگر به ما ارسال شود تا اینکه به یک چاپگر در جایی دیگر ارسال شود. منظور از دستیابی به این هدف این است که پیچیدگی سیستمهای توزیع شده باید از دید کاربر مخفی بماند تا تاثیر مخربی بر روی کاربر نداشته باشد؛ در صورتیکه نیاز کاربر به عدم شفافیت برخی از قسمتهای سیستم باشد بهتر است درجههایی را برای سیستمهای توزیع شده در نظر بگیریم.
3- Openness: باز بودن یا قابل گسترش بودن سیستمهای توزیع شده یکی دیگر از اهداف بسیار مهم این سیستمها میباشد. به این صورت که یک سیستم در حال اجرا باید توانایی اضافه کردن منابع جدید را داشته باشد. بطور مثال با افزوده شدن نیازمندیهای جدید، نیاز میشود که یک زیر سیستم جدید یا Component جدید را پیاده سازی کنیم. قسمت جدید به راحتی و بدون تاثیر در جریان تعامل کاربر باید بتواند به سیستم اضافه شود. در اکثر موارد این هدف با استفاده از یکسری قراردادهای مشخص که تمامی زیر سیستمها آنها را میشناسند و رعایت میکنند، محقق میشود.
4- Scalability: مقیاس پذیری سیستمهای توزیع شده بدین معنی است که با رشد مواردی مانند تعداد پردازش و درخواست یا موقعیت جغرافیایی کاربران، سیستم قادر باشد بدون تاثیر بر جریان تعامل کاربر با سیستم، آنها را پوشش دهد. یعنی بطور مثال زمانیکه تعداد درخواستهای کاربران سیستم افزایش مییابد، با Replicate قسمتهای موجود سیستم در سخت افزارهای جدید میتوانیم بار پردازشی را بین تعداد بیشتری از Nodeها تقسیم کنیم. به این صورت سیستم میتواند بدون از دسترس خارج شدن، تعداد بیشتری از درخواستهای کاربران را پوشش دهد. یا زمانیکه قرار است موقعیتهای جدید جغرافیایی را سیستم پوشش دهد، با اضافه کردن منابع مورد نیاز، در آن موقعیت جغرافیایی، سیستم قادر است نیاز کاربران آن مکان جغرافیایی را برآورده کند.
تا به این قسمت از سری مقالات سیستمهای توزیع شده، هدف من این بوده که با چرایی وجود این نوع از سیستمها و نحوهی انتخاب آنها و اهداف سیستمهای توزیع شده آشنا شوید. در بخشهای بعد، روشهای مختلف طراحی و پیاده سازی سیستمهای توزیع شده را مورد بررسی قرار میدهیم و میبینیم که چه ابزارهایی برای پیاده سازی سیستمهای توزیع شده در NET. وجود دارند و با توجه به نوع کارآیی هر یک از این ابزارها، آنها را بصورت جداگانه مورد استفاده قرار میدهیم تا با مزایا و معایب هریک آشنا شویم. البته این را نیز ذکر کنم که با توجه به تعاریف سیستمهای توزیع شده، انواع مختلفی از سیستمهای توزیع شده وجود دارند که ما از قبل با برخی از آنها آشنا هستیم؛ معماریهایی مانند Client/Server یا N-Tier نمونههایی از سیستمهای توزیع شده هستند که در آنها وظایف، در سخت افزارهای متفاوتی تقسیم شده و ارتباط هر قسمت از طریق سرویسهایی که ما پیاده سازی میکنیم، صورت میپذیرد و به دلیل اینکه مطمئنا همه شما با نحوه طراحی و پیاده سازی آنها و نحوه ارتباط قسمتهای مختلف آنها آشنا هستید، در سری مقالات سیستمهای توزیع شده در NET.، دیگر نیازی به توضیحی در مورد آنها نمیباشد. هدف من از قسمتهای مرتبط با پیاده سازی سیستمهای توزیع شده، چگونگی تکامل معماریهایی مانند N-Tier بوسیله ابزارهایی است که با هدف دستیابی به خصوصیات و اهداف سیستمهای توزیع شده بوجود آمدهاند.
کدهای یک دایرکتیو سفارشی نمایش و یا مخفی سازی قسمتهای مختلف صفحه را بر اساس سطوح دسترسی کاربر جاری، در IsVisibleForAuthUserDirective مشاهده کردید. روش دیگر انجام اینکار، نوشتن یک دایرکتیو ساختاری شبیه به ngIf توکار خود Angular است. کاری که ngIf انجام میدهد، مخفی کردن یک المان در صفحه نیست؛ بلکه کل آنرا از DOM حذف میکند.
نکتهی اصلی پیاده سازی یک دایرکتیو ساختاری
اگر به سازندهی IsVisibleForAuthUserDirective دقت کنید، تزریق وابستگی ElementRef را داریم:
@Directive({ selector: "[isVisibleForAuthUser]" }) export class IsVisibleForAuthUserDirective implements OnInit, OnDestroy { constructor(private elem: ElementRef, private authService: AuthService) { }
برای ایجاد یک دایرکتیور ساختاری، نیاز است از تزریق TemplateRef و ViewContainerRef استفاده کرد:
@Directive({ selector: "[hasAuthUserViewPermission]" }) export class HasAuthUserViewPermissionDirective implements OnInit, OnDestroy { constructor( private templateRef: TemplateRef<any>, private viewContainer: ViewContainerRef, private authService: AuthService ) { }
<div *hasAuthUserViewPermission="['Admin','User']"> *hasAuthUserViewPermission="['Admin','User']" </div>
this.viewContainer.createEmbeddedView(this.templateRef);
this.viewContainer.clear();
اگر این نکات را کنار هم قرار دهیم و کدهای IsVisibleForAuthUserDirective فوق را بر این اساس اصلاح کنیم، به قطعه کد زیر میرسیم:
import { Directive, Input, OnDestroy, OnInit, TemplateRef, ViewContainerRef } from "@angular/core"; import { Subscription } from "rxjs/Subscription"; import { AuthService } from "./../../core/services/auth.service"; @Directive({ selector: "[hasAuthUserViewPermission]" }) export class HasAuthUserViewPermissionDirective implements OnInit, OnDestroy { private isVisible = false; private requiredRoles: string[] | null = null; private subscription: Subscription | null = null; @Input() set hasAuthUserViewPermission(roles: string[] | null) { this.requiredRoles = roles; } // Note, if you don't place the * in front, you won't be able to inject the TemplateRef<any> or ViewContainerRef into your directive. constructor( private templateRef: TemplateRef<any>, private viewContainer: ViewContainerRef, private authService: AuthService ) { } ngOnInit() { this.subscription = this.authService.authStatus$.subscribe(status => this.changeVisibility(status)); this.changeVisibility(this.authService.isAuthUserLoggedIn()); } ngOnDestroy(): void { if (this.subscription) { this.subscription.unsubscribe(); } } private changeVisibility(status: boolean) { const isInRoles = !this.requiredRoles ? true : this.authService.isAuthUserInRoles(this.requiredRoles); if (isInRoles && status) { if (!this.isVisible) { this.viewContainer.createEmbeddedView(this.templateRef); this.isVisible = true; } } else { this.isVisible = false; this.viewContainer.clear(); } } }
سپس تعریف آنرا به قسمتهای declarations و exports مربوط به SharedModule اضافه میکنیم:
import { HasAuthUserViewPermissionDirective } from "./directives/has-auth-user-view-permission.directive"; @NgModule({ declarations: [ HasAuthUserViewPermissionDirective ], exports: [ HasAuthUserViewPermissionDirective ] }) export class SharedModule {}
اکنون ماژول Dashboard برای استفادهی از این امکانات تنها کافی است SharedModule را دریافت کند (یا هر ماژول دیگری نیز به همین ترتیب است):
import { SharedModule } from "../shared/shared.module"; @NgModule({ imports: [ SharedModule ] }) export class DashboardModule { }
پس از آن برای مخفی سازی یک المان از دید کاربران وارد نشدهی به سیستم، فقط کافی است دایرکتیو ساختاری hasAuthUserViewPermission را به المان اعمال کنیم:
<div *hasAuthUserViewPermission=""> *hasAuthUserViewPermission="" </div>
<div *hasAuthUserViewPermission="['Admin','User']"> *hasAuthUserViewPermission="['Admin','User']" </div>
خلاصهی این تغییرات به کدهای نهایی این سری اعمال شدهاند.
Here’s what’s new in this preview release:
- Improved Blazor accessibility
- Required Blazor component parameters
- Efficient byte array transfers for JavaScript interop
- Optional parameters for view component tag helpers
- Angular template updated to Angular 12
- OpenAPI support for minimal APIs
- Inject services into minimal APIs without
[FromServices]
attribute - Configure the accept socket for Kestrel
-
IHttpActivityFeature
- Long running activity tag for SignalR connections
- WebSocket compression
- SignalR WebSockets TestServer support
- New
OnCheckSlidingExpiration
event for controlling cookie renewal - ClientCertificateMode.DelayCertificate