یک برنامهی Vue.js را ایجاد کنید و سپس یک پوشه را در فولدر src بنام mixins بسازید. در این پوشه یک فایل را با نام دلخواهی از نوع جاوااسکریپت، ایجاد کنید و محتوای زیر را در آن قرار دهید:
export default { data() { return { title: 'Mixins are cool', copyright: 'All rights reserved. Product of super awesome people' }; }, created: function () { this.greetings(); }, methods: { greetings() { console.log('Howdy my good fellow!'); } } };
برای استفاده از mixin بشکل زیر عمل میکنیم. در واقع کد زیر شامل تمام موارد تعریف شده در myMixin.js میباشد.
<script> import myMixin from './mixins/myMixin' export default { name: 'app', //را دریافت میکند mixins آرایه ای از mixins:[myMixin] } </script> <style>
نکته: در صورتیکه بین mixin و کامپوننت، دادههای همنامی وجود داشته باشد، اولویت با داده یا تابعی است که در خود کامپوننت تعریف شدهاست. مثال زیر را در نظر بگیرید:
export default { data() { return { blogName: 'google.com' }; }, methods: { print() { console.log(this.blogName); } } };
و در کامپوننتی که از mixin فوق استفاده میکند:
<script> import myMixin from "./mixins/myMixin"; import duplicateFuncData from "./mixins/duplicateFuncData"; export default { name: "app", data() { return { // و کامپوننت جاری تکراری ست mixin نام این متغیر در blogName: "microsoft.com" }; }, methods: { // و کامپوننت جاری تکراری ست ولی عملکرد متفاوت دارد mixin نام این تابع در print() { alert(this.blogName); } }, components: {}, //را دریافت میکند mixins آرایه ای از mixins: [myMixin, duplicateFuncData] }; </script>
و نتیجهی اجرا:
تعریف mixin بصورت سراسری: وقتی یک mixin را بصورت global تعریف میکنیم، تمام نمونههای وهله سازی شده از vue، دارای قابلیتهای تعریف شدهی در mixin میباشند. کد main.js را بشکل زیر تغییر میدهیم. اکنون با اجرای برنامه، به ازای هر نمونهای از vue که وهله سازی میشود، تابع زیر اجرا میگردد.
import Vue from 'vue' import App from './App.vue' Vue.config.productionTip = false // بصورت سراسری تعریف شده Vue.mixin({ created: function () { alert('from global mixin') } }) new Vue({ render: h => h(App), }).$mount('#app')
نتیجهگیری:
1) استفاده از mixin باعث اجتناب از تکرار کدها و دادههای تکراری میشود (DRY).
2) از mixin در ساخت پلاگین برای Vue.js استفاده میشود.
// 3. inject some component options Vue.mixin({ created: function () { // some logic ... } ... })
3) اگر mixin و کامپوننتی که از mixin استفاده میکند، هر دو توابع lifecycle را پیاده سازی کرده باشند، اول توابع lifecycle مربوط به mixin اجرا میشود و سپس توابع lifecycle مربوط به کامپوننت.
4) اگر دو کامپوننت، mixin مشترکی را استفاده کنند، دادههای آنها share نخواهد شد و برای اینکه دو کامپوننتی که از mixin واحدی استفاده میکنند بتوانند از دادههای یکسانی در mixin استفاده کنند، نیاز به تزریق وابستگی دارند.
5) اگر از ادغام قسمت جاوااسکریپتی و HTML مربوط به کامپوننتها ناراضی هستید، یک راه حل جداسازی، استفاده از mixin به ازای هر کامپوننت است.
6) استفاده از mixin باعث به روزسانی، نگهداری و توسعهی سادهتر و همچنین ماژولار بودن برنامه میشود.
نکته: برای اجرای برنامه و دریافت پکیجهای مورد استفاده در مثال جاری، نیاز است دستور زیر را اجرا کنید:
npm install
public class ProductViewModel { public int ProductId { get; set; } public string Name { get; set; } public string Description { get; set; } public string ImageUrl { get; set; } public decimal UnitPrice { get; set; } }
public record ProductDTO(int Id, string Name, string Description);
public record ProductDTO { public int Id { get; init; } public string Name { get; init; } } var dto = new ProductDTO { Id = 1, Name = "some name" };
public class Product : DataObject<Product> { public Product(int id) { Id = id; InitializeFromDatabase(); } private void InitializeFromDatabase() { DataHelpers.LoadFromDatabase(this); } public int Id { get; private set; } // other properties and methods }
public class Product { public Product(int id) { Id = id; } private Product() { // required for EF } public int Id { get; private set; } // other properties and methods }
- برای اجرای وظایف خود به فریم ورک ثالثی وابسته نیست.
- به کلاس پایهای ( Base class) نیاز ندارد.
- وابستگی به متد استاتیکی ندارد.
- می تواند در هر جایی از پروژه، نمونه سازی شود.
- اصل Persistence Ignorant را بیشتر رعایت کرده، نه بطور کامل؛ چون یک سازنده دارد که به کتابخانهی ثالثی نیازمند است (سازندهی بدون پارامتر که مورد نیاز EF میباشد).
MongoDB #12
>db.COLLECTION_NAME.ensureIndex({KEY:1})
>db.mycol.ensureIndex({"title":1})
>db.mycol.ensureIndex({"title":1,"description":-1})
پارامتر | نوع داده | توضیحات |
background | Boolean | ایندکس را در پس زمینه میسازد؛ بنابراین عمل ساخت ایندکس، بقیه فعالیتهای پایگاه داده را مسدود یا متوقف نمیکند. برای این کار مقدار را true تعیین کنید. مقدار پیش فرض false است. |
unique | Boolean | یک ایندکس یکتا را میسازد. در این حالت مجموعه، اجازه درج سندهایی را که مقدار کلید یا کلیدهای آنها از قبل وجود دارند، نخواهد داد. برای ساخت یک ایندکس یکتا مقدار را true تعیین کنید. مقدار پیش فرض آن false است. |
name | string | نام ایندکس. اگر تعیین نشود MongoDB نام خودکاری را توسط الحاق نام فیلدها و ترتیب مرتب سازی تولید میکند. |
dropDups | Boolean | ایندکسی را بر روی فایل میسازد که ممکن است مقادیر تکراری داشته باشد. MongoDB فقط اولین پیشامد از یک کلید را ایندکس میکند و همه سندهایی را که پیشامد ثانویه کلید هستند، از مجموعه حذف میکند. برای ساخت ایندکس یکتا مقدار را true تعیین کنید. مقدار پیش فرض آن false است. |
sparse | Boolean | اگر مقدار آن true تعیین شود، ایندکس فقط به سندهایی با فیلد تعیین شده رجوع میکند. این ایندکسها از فضای کمی استفاده کرده و در برخی موقعیتها متفاوت رفتار میکنند. مقدار پیش فرض آن false است. |
expireAfterSeconds | integer | تعیین یک مقدار به ثانیه بعنوان TTL، برای کنترل کردن اینکه چه مدت MongoDB اسناد را در این مجموعه نگه دارد. |
v | index version | شمارهی نسخه ایندکس. نسخهی ایندکس پیش فرض بستگی به نسخه mongod درحال اجرای هنگام ساخت ایندکس دارد. |
weights | document | وزن یک عدد بین 1 تا 99999 است و مشخص کنندهی اهمیت فیلد با دیگر فیلدهای ایندکس شده از نظر امتیاز است. |
default_language | string | برای یک ایندکس متنی، زبانی برای تعیین کردن لیست کلمات متوقف کننده و نقش هایی برای ریشهیابی و نشانه گذاری کلمات. |
language_override | string | برای یک ایندکس متنی، تعیین کننده نام فیلد در سند که شامل زبانی برای لغو کردن زبان پیش فرض است. مقدار پیش فرض آن language است. |
MVC vs 3-Tier Pattern
Memento یک الگوی طراحی مفید و ساده است که برای ذخیره و بازیابی state یک object استفاده میشود. در بعضی از مقالات از آن به عنوان snapshot نیز یاد شده است! اگر با git کار کرده باشید، این مفهوم را میتوان در git بسیار یافت؛ هر commit به عنوان یک snapshot میباشد که میتوان به صورت مکرر آن را undo کرد و یا مثال خیلی سادهتر میتوان به ctrl+z در سیستم عامل اشاره کرد.
به مثال زیر توجه کنید:
Int temp; Int a=1; temp=a; a=2; . . a=temp;
شما قطعا در برنامه نویسی با کد بالا زیاد برخورد داشتهاید و آنرا به صورت مکرر انجام دادهاید. کد بالا را در قالب یک object بیان میکنیم. به مثال زیر توجه کنید:
int main() { MyClass One = new MyClass(); MyClass Temp = new MyClass(); // Set an initial value. One.Value = 10; One.Name = "Ten"; // Save the state of the value. Temp.Value = One.Value; Temp.Name = One.Name; // Change the value. One.Value = 99; One.Name = "Ninety Nine"; // Undo and restore the state. One.Value = Temp.Value; One.Name = Temp.Name; }
در کد بالا با استفاده از یک temp، شیء مورد نظر را ذخیره کرده و در آخر مجدد دادهها را درون شیء، restore میکنیم.
از مشکلات کد بالا میتوان گفت :
۱- برای هر object باید یک شیء temp ایجاد کنیم.
۲- ممکن است بخواهیم که حالات یک object را بر روی هارد ذخیره کنیم. با روش فوق کدها خیلی پیچیدهتر خواهند شد.
۳- نوشتن کد به این سبک برای پروژههای بزرگ، پیچیده و مدیریت آن سختتر میشود.
پیاده سازی memento
ما این مثال را در قالب یک پروژه NET Core onsole. ایجاد میکنیم. برای این کار یک پوشهی جدید را ایجاد و درون ترمینال دستور زیر را وارد کنید:
dotnet new console
روشهای زیادی برای پیاده سازی memento وجود دارند. برای پیاده سازی memento ابتدا یک abstract class را به شکل زیر ایجاد میکنیم:
abstract class MementoBase { protected Guid mementoKey = Guid.NewGuid(); abstract public void SaveMemento(Memento memento); abstract public void RestoreMemento(Memento memento); }
اگر به کلاس بالا دقت کنید، این کلاس قرار است parent کلاسهای دیگری باشد که داری دو متد SaveMemento و RestoreMemento برای ذخیره و بازیابی و همچنین یک Guid برای نگهداری stateهای مختلف میباشد.
ورودی متدها از نوع memento میباشد. پس کلاس memento را به شکل زیر ایجاد میکنیم:
class Memento { private Dictionary<Guid, object> stateList = new Dictionary<Guid, object>(); public object GetState(Guid key) { return stateList[key]; } public void SetState(Guid key, object newState) { stateList[key] = newState; } public Memento() { } }
در کد بالا با یک Dictionary میتوان هر object را با کلیدش ذخیره کنیم. توجه کنید که value دیکشنری از نوع object میباشد و چون object پدر تمام objectهای دیگر است پس میتوانیم هر نوع دادهای را در آن ذخیره کنیم. تا اینجا، Memento پیاده سازی شده است. میتوان این کار را با جنریکها نیز پیاده سازی کرد.
در ادامه میخواهیم یک کلاس بسازیم و حالتهای مختلف را در آن بررسی کنیم. کلاس زیر را ایجاد کنید:
class ConcreteOriginator : MementoBase { private int value = 0; public ConcreteOriginator(int newValue) { SetData(newValue); } public void SetData(int newValue) { value = newValue; } public void Speak() { Console.WriteLine("My value is " + value.ToString()); } public override void SaveMemento(Memento memento) { memento.SetState(mementoKey, value); } public override void RestoreMemento(Memento memento) { int restoredValue = (int)memento.GetState(mementoKey); SetData(restoredValue); } }
کلاس ConcreteOriginator از کلاس MementoBase ارث بری کرده و دو متد RestoreMemento و SaveMemento را پیاده سازی میکند و همچنین دارای یک مشخصه value میباشد. برای خروجی گرفتن، متد main را به صورت زیر پیاده سازی میکنیم:
static void Main(string[] args) { Memento memento = new Memento(); // Create an originator, which will hold our state data. ConcreteOriginator myOriginator = new ConcreteOriginator("Hello World!", StateType.ONE); ConcreteOriginator anotherOriginator = new ConcreteOriginator("Hola!", StateType.ONE); ConcreteOriginator2 thirdOriginator = new ConcreteOriginator2(7); // Set some state data. myOriginator.Speak(); anotherOriginator.Speak(); thirdOriginator.Speak(); // Save the states into our memento. myOriginator.SaveMemento(memento); anotherOriginator.SaveMemento(memento); thirdOriginator.SaveMemento(memento); // Now change our originators' states. myOriginator.SetData("Goodbye!", StateType.TWO); anotherOriginator.SetData("Adios!", StateType.TWO); thirdOriginator.SetData(99); myOriginator.Speak(); anotherOriginator.Speak(); thirdOriginator.Speak(); // Restore our originator's state. myOriginator.RestoreMemento(memento); anotherOriginator.RestoreMemento(memento); thirdOriginator.RestoreMemento(memento); myOriginator.Speak(); anotherOriginator.Speak(); thirdOriginator.Speak(); Console.ReadKey(); }
Hello World! I'm in state ONE Hola! I'm in state ONE My value is 7 Goodbye! I'm in state TWO Adios! I'm in state TWO My value is 99 Hello World! I'm in state ONE Hola! I'm in state ONE My value is 7
AngularJS #1
معماری میکروسرویسها
معماری Monolithic چیست؟
مشکلات معماری Monolithic
- در معماری Monolithic زمانیکه ترافیک برنامه در سمت سرور افزایش پیدا میکند، باید برای پاسخگویی، اندازه را افزایش داد. یعنی باید برنامه تحت وب خود را بر روی سرورهای مختلف مجددا اجرا نمود. بخشی به نام Load Balancer، وظیفه توزیع درخواستها را به سرورهای مختلف که بر روی هر یک، یک نسخه از برنامه در حال اجرا است، به عهده دارد. بر اساس توضیحی که از این معماری ارایه شد، در هر یک از این اجراها، کل برنامه با تمام متعلقاتی که دارد، فارغ از اینکه به همه آنها نیاز است یا نه، از منابع سرور استفاده میکند.
- در معماری Monolithic برنامهها بر اساس یک زبان برنامهنویسی مشخص، برای یک فریم ورک مشخص نوشته میشوند. این برنامهها اصطلاحا چند سکویی نیستند و کامپوننتهای نوشته شده برای آنها فقط در فریم ورک جاری قابل استفاده مجدد هستند.
- ممکن است برای هر تغییر ریز و درشت در برنامههای این معماری، نیاز به Build و Deploy مجدد کل برنامه باشد که احتمال از دسترس خارج شدن برنامه هم وجود دارد.
- اگر بخشی از برنامه از کار بیافتد، ممکن است باعث از کار افتادن کل برنامه یا بخشهایی از آن شود.
معماری Microservices
ارزش معماری Microservices
- از آنجایی که سرویسها از طریق زبان مشترک شبکه با یکدیگر در ارتباط هستند، میشود آنها را با زبانهای برنامهنویسی مختلف و بر روی فریمفرکهای متفاوت نوشت.
- بدیهی است که با این معماری، هر سرویس را میشود به صورت جداگانه ایجاد کرد و تغییر داد که باعث سرعت در به روزرسانی و فرآیند گسترش برنامه میشود.
- مانیتور کردن سرویسها سادهتر خواهد بود. از آنجایی که هر سرویس به صورت یک پردازش جداگانه اجرا خواهد شد، تعیین اینکه هر سرویس از چه منابعی و به چه اندازهای استفاده میکند، آسانتر خواهد بود.
- از آنجایی که این سرویسها از طریق شبکه در تبادل هستند، میشود از آنها در سایر برنامهها مجدداً استفاده کرد.
افزایش یک سرویس خاص
مشکلات معماری Microservices
- از آنجایی که برنامههای سمت سرور نوشته شده با این معماری به سرویسهای مختلفی تقسیم میشوند، گسترش و تنظیمات آنها میتواند کاری وقت گیر و طاقت فرسایی باشد.
- از آنجایی که ارتباط بین سرویسها در بستر شبکه انجام میشود، انتظار کندی عملکرد سرویسها دور از ذهن نیست.
- به دلیل ارتباطات شبکهای، احتمال آسیب پذیریهای امنیتی در این نوع برنامهها بیشتر است.
- نوشتن سرویسهایی که در بستر شبکه با سایر سرویسها در ارتباط هستند سختی و مشکلات خود را دارد. برنامهنویس در این شرایط، درگیر برقراری ارتباط، رمزگذاری دادهها در صورت نیاز و تبدیل آنها میشود.
- به دلیل مجزا بودن بخشهای مختلف برنامه، مانیتور کردن و ردیابی عملکرد سرویسها، یکی از کارهای اصلی توسعه دهنده یا استفاده کننده از برنامه است.
- در مجموع سرعت برنامههای نوشته شده با معماری Microservices کندتر از برنامههای نوشته شده با معماری Monolithic است. دلیل آن محیط اجرایی برنامهها است. برنامههایی با معماری Monolithic بر روی حافظه سرور پردازش میشوند.
چه زمانی از معماری Microservices استفاده کنیم؟
مدیریت دادهها:
پیادهسازی معماری Microservicesها توسط فریمفرک Seneca
سیستم ASP.NET Membership بهمراه ASP.NET 2.0 در سال 2005 معرفی شد، و از آن زمان تا بحال تغییرات زیادی در چگونگی مدیریت احزار هویت و اختیارات کاربران توسط اپلیکیشنهای وب بوجود آمده است. ASP.NET Identity نگاهی تازه است به آنچه که سیستم Membership هنگام تولید اپلیکیشنهای مدرن برای وب، موبایل و تبلت باید باشد.
پیش زمینه: سیستم عضویت در ASP.NET
- الگوی پایگاه داده آن برای SQL Server طراحی شده است، و قادر به تغییرش هم نیستید. میتوانید اطلاعات پروفایل را اضافه کنید، اما تمام دادهها در یک جدول دیگر ذخیره میشوند، که دسترسی به آنها نیز مشکلتر است، تنها راه دسترسی Profile Provider API خواهد بود.
- سیستم تامین کننده (Provider System) امکان تغییر منبع دادهها را به شما میدهد، مثلا میتوانید از بانکهای اطلاعاتی MySQL یا Oracle استفاده کنید. اما تمام سیستم بر اساس پیش فرض هایی طراحی شده است که تنها برای بانکهای اطلاعاتی relational درست هستند. میتوانید تامین کننده (Provider) ای بنویسید که دادههای سیستم عضویت را در منبعی به غیر از دیتابیسهای relational ذخیره میکند؛ مثلا Windows Azure Storage Tables. اما در این صورت باید مقادیر زیادی کد بنویسید. مقادیر زیادی هم System.NotImplementedException باید بنویسید، برای متد هایی که به دیتابیسهای NoSQL مربوط نیستند.
- از آنجایی که سیستم ورود/خروج سایت بر اساس مدل Forms Authentication کار میکند، سیستم عضویت نمیتواند از OWIN استفاده کند. OWIN شامل کامپوننت هایی برای احراز هویت است که شامل سرویسهای خارجی هم میشود (مانند Microsoft Accounts, Facebook, Google, Twitter). همچنین امکان ورود به سیستم توسط حسابهای کاربری سازمانی (Organizational Accounts) نیز وجود دارد مانند Active Directory و Windows Azure Active Directory. این کتابخانه از OAuth 2.0، JWT و CORS نیز پشتیبانی میکند.
- ذخیره دادههای سیستم عضویت در بانکهای اطلاعاتی non-relational مشکل است.
- نمی توانید از آن در کنار OWIN استفاده کنید.
- با فراهم کنندههای موجود ASP.NET Membership بخوبی کار نمیکند. توسعه پذیر هم نیست.
ASP.NET Universal Providers
ASP.NET Universal Providers برای ذخیره سازی اطلاعات سیستم عضویت در Windows Azure SQL Database توسعه پیدا کردند. با SQL Server Compact هم بخوبی کار میکنند. این تامین کنندهها بر اساس Entity Framework Code First ساخته شده بودند و بدین معنا بود که دادههای سیستم عضویت را میتوان در هر منبع داده ای که توسط EF پشتیبانی میشود ذخیره کرد. با انتشار این تامین کنندهها الگوی دیتابیس سیستم عضویت نیز بسیار سبکتر و بهتر شد. اما این سیستم بر پایه زیر ساخت ASP.NET Membership نوشته شده است، بنابراین محدودیتهای پیشین مانند محدودیتهای SqlMembershipProvider هنوز وجود دارند. به بیان دیگر، این سیستمها همچنان برای بانکهای اطلاعاتی relational طراحی شده اند، پس سفارشی سازی اطلاعات کاربران و پروفایلها هنوز مشکل است. در آخر آنکه این تامین کنندهها هنوز از مدل احراز هویت فرم استفاده میکنند.
ASP.NET Identity
- یک سیستم هویت واحد (One ASP.NET Identity system)
- سیستم ASP.NET Identity میتواند در تمام فریم ورکهای مشتق از ASP.NET استفاده شود. مانند ASP.NET MVC, Web Forms, Web Pages, Web API و SignalR
- از این سیستم میتوانید در تولید اپلیکیشنهای وب، موبایل، استور (Store) و یا اپلیکیشنهای ترکیبی استفاده کنید.
- سادگی تزریق دادههای پروفایل درباره کاربران
- روی الگوی دیتابیس برای اطلاعات کاربران و پروفایلها کنترل کامل دارید. مثلا میتوانید به سادگی یک فیلد، برای تاریخ تولد در نظر بگیرید که کاربران هنگام ثبت نام در سایت باید آن را وارد کنند.
- کنترل ذخیره سازی/واکشی اطلاعات
- بصورت پیش فرض ASP.NET Identity تمام اطلاعات کاربران را در یک دیتابیس ذخیره میکند. تمام مکانیزمهای دسترسی به دادهها توسط EF Code First کار میکنند.
- از آنجا که روی الگوی دیتابیس، کنترل کامل دارید، تغییر نام جداول و یا نوع داده فیلدهای کلیدی و غیره ساده است.
- استفاده از مکانیزمهای دیگر برای مدیریت دادههای آن ساده است، مانند SharePoint, Windows Azure Storage Table و دیتابیسهای NoSQL.
- تست پذیری
- ASP.NET Identity تست پذیری اپلیکیشن وب شما را بیشتر میکند. میتوانید برای تمام قسمت هایی که از ASP.NET Identity استفاده میکنند تست بنویسید.
- تامین کننده نقش (Role Provider)
- تامین کننده ای وجود دارد که به شما امکان محدود کردن سطوح دسترسی بر اساس نقوش را میدهد. بسادگی میتوانید نقشهای جدید مانند "Admin" بسازید و بخشهای مختلف اپلیکیشن خود را محدود کنید.
- Claims Based
- ASP.NET Identity از امکان احراز هویت بر اساس Claims نیز پشتیبانی میکند. در این مدل، هویت کاربر بر اساس دسته ای از اختیارات او شناسایی میشود. با استفاده از این روش توسعه دهندگان برای تعریف هویت کاربران، آزادی عمل بیشتری نسبت به مدل Roles دارند. مدل نقشها تنها یک مقدار منطقی (bool) است؛ یا عضو یک نقش هستید یا خیر، در حالیکه با استفاده از روش Claims میتوانید اطلاعات بسیار ریز و دقیقی از هویت کاربر در دست داشته باشید.
- تامین کنندگان اجتماعی
- به راحتی میتوانید از تامین کنندگان دیگری مانند Microsoft, Facebook, Twitter, Google و غیره استفاده کنید و اطلاعات مربوط به کاربران را در اپلیکیشن خود ذخیره کنید.
- Windows Azure Active Directory
- برای اطلاعات بیشتر به این لینک مراجعه کنید.
- یکپارچگی با OWIN
- ASP.NET Identity بر اساس OWIN توسعه پیدا کرده است، بنابراین از هر میزبانی که از OWIN پشتیبانی میکند میتوانید استفاده کنید. همچنین هیچ وابستگی ای به System.Web وجود ندارد. ASP.NET Identity یک فریم ورک کامل و مستقل برای OWIN است و میتواند در هر اپلیکیشنی که روی OWIN میزبانی شده استفاده شود.
- ASP.NET Identity از OWIN برای ورود/خروج کاربران در سایت استفاده میکند. این بدین معنا است که بجای استفاده از Forms Authentication برای تولید یک کوکی، از OWIN CookieAuthentication استفاده میشود.
- پکیج NuGet
- ASP.NET Identity در قالب یک بسته NuGet توزیع میشود. این بسته در قالب پروژههای ASP.NET MVC, Web Forms و Web API که با Visual Studio 2013 منتشر شدند گنجانده شده است.
- توزیع این فریم ورک در قالب یک بسته NuGet این امکان را به تیم ASP.NET میدهد تا امکانات جدیدی توسعه دهند، باگها را برطرف کنند و نتیجه را بصورت چابک به توسعه دهندگان عرضه کنند.
ASP.NET Identity در قالب پروژههای ASP.NET MVC, Web Forms, Web API و SPA که بهمراه Visual Studio 2013 منتشر شده اند استفاده میشود. در ادامه به اختصار خواهیم دید که چگونه ASP.NET Identity کار میکند.
- یک پروژه جدید ASP.NET MVC با تنظیمات Individual User Accounts بسازید.
-
پروژه ایجاد شده شامل سه بسته میشود که مربوط به ASP.NET Identity هستند:
- Microsoft.AspNet.Identity.EntityFramework این بسته شامل پیاده سازی ASP.NET Identity با Entity Framework میشود، که تمام دادههای مربوطه را در یک دیتابیس SQL Server ذخیره میکند.
- Microsoft.AspNet.Identity.Core این بسته محتوی تمام interfaceهای ASP.NET Identity است. با استفاده از این بسته میتوانید پیاده سازی دیگری از ASP.NET Identity بسازید که منبع داده متفاوتی را هدف قرار میدهد. مثلا Windows Azure Storage Table و دیتابیسهای NoSQL.
- Microsoft.AspNet.Identity.OWIN این بسته امکان استفاده از احراز هویت OWIN را در اپلیکیشنهای ASP.NET فراهم میکند. هنگام تولید کوکیها از OWIN Cookie Authentication استفاده خواهد شد.
هنگامیکه بر روی دکمهی Register کلیک شود، کنترلر Account، اکشن متد Register را فراخوانی میکند تا حساب کاربری جدیدی با استفاده از ASP.NET Identity API ساخته شود.
[HttpPost] [AllowAnonymous] [ValidateAntiForgeryToken] public async Task<ActionResult> Register(RegisterViewModel model) { if (ModelState.IsValid) { var user = new ApplicationUser() { UserName = model.UserName }; var result = await UserManager.CreateAsync(user, model.Password); if (result.Succeeded) { await SignInAsync(user, isPersistent: false); return RedirectToAction("Index", "Home"); } else { AddErrors(result); } } // If we got this far, something failed, redisplay form return View(model); }
اگر حساب کاربری با موفقیت ایجاد شود، کاربر توسط فراخوانی متد SignInAsync به سایت وارد میشود.
[HttpPost] [AllowAnonymous] [ValidateAntiForgeryToken] public async Task<ActionResult> Register(RegisterViewModel model) { if (ModelState.IsValid) { var user = new ApplicationUser() { UserName = model.UserName }; var result = await UserManager.CreateAsync(user, model.Password); if (result.Succeeded) { await SignInAsync(user, isPersistent: false); return RedirectToAction("Index", "Home"); } else { AddErrors(result); } } // If we got this far, something failed, redisplay form return View(model); }
private async Task SignInAsync(ApplicationUser user, bool isPersistent) { AuthenticationManager.SignOut(DefaultAuthenticationTypes.ExternalCookie); var identity = await UserManager.CreateIdentityAsync( user, DefaultAuthenticationTypes.ApplicationCookie); AuthenticationManager.SignIn( new AuthenticationProperties() { IsPersistent = isPersistent }, identity); }
از آنجا که ASP.NET Identity و OWIN Cookie Authentication هر دو Claims-based هستند، فریم ورک، انتظار آبجکتی از نوع ClaimsIdentity را خواهد داشت. این آبجکت تمامی اطلاعات لازم برای تشخیص هویت کاربر را در بر دارد. مثلا اینکه کاربر مورد نظر به چه نقش هایی تعلق دارد؟ و اطلاعاتی از این قبیل. در این مرحله میتوانید Claimهای بیشتری را به کاربر بیافزایید.
کلیک کردن روی لینک Log off در سایت، اکشن متد LogOff در کنترلر Account را اجرا میکند.
// POST: /Account/LogOff [HttpPost] [ValidateAntiForgeryToken] public ActionResult LogOff() { AuthenticationManager.SignOut(); return RedirectToAction("Index", "Home"); }
همانطور که مشاهده میکنید برای ورود/خروج کاربران از AuthenticationManager استفاده میشود که متعلق به OWIN است. متد SignOut همتای متد FormsAuthentication.SignOut است.
کامپوننتهای ASP.NET Identity
تصویر زیر اجزای تشکیل دهنده ASP.NET Identity را نمایش میدهد. بسته هایی که با رنگ سبز نشان داده شده اند سیستم کلی ASP.NET Identity را میسازند. مابقی بستهها وابستگی هایی هستند که برای استفاده از ASP.NET Identity در اپلیکیشنهای ASP.NET لازم اند.
دو پکیج دیگر نیز وجود دارند که به آنها اشاره نشد:
- Microsoft.Security.Owin.Cookies این بسته امکان استفاده از مدل احراز هویت مبتنی بر کوکی (Cookie-based Authentication) را فراهم میکند. مدلی مانند سیستم ASP.NET Forms Authentication.
- EntityFramework که نیازی به معرفی ندارد.
مهاجرت از Membership به ASP.NET Identity
قدمهای بعدی
یادگیری مدل در داده کاوی
مقدمه
هدف اصلی داده کاوی کشف دانش است، که این دانش نظمی که در دادهها وجود دارد را نمایان میسازد. پس از کشف دانش ممکن است با دو وضعیت مواجه شویم:- حالت اول هنگامی است که افراد خبره در دامنه داده مورد کاوش، آگاه به دانش استخراج شده باشند که در این صورت آن دانش به عنوان یک قانون صحیح تلقی خواهد شد.
- در حالت دوم ممکن است دانش کشف شده، یک دانش جدید بوده و در بین افراد خبره در آن حوزه شناخته شده نباشد، در این صورت این دانش بررسی شده و در صورت منطقی بودن تبدیل به فرضیه شده و در نهایت درست یا غلط بودن این فرضیه با آزمایشات و بررسیهای متعدد اثبات میشود و در صورت درست بودن فرضیه تبدیل به قانون خواهد شد.
روشهای یادگیری مدل در داده کاوی
پیشتر به معرفی مراحل کاری در داده کاوی که مشتمل بر سه مرحله اساسی: آماده سازی داده، یادگیری مدل و در نهایت ارزیابی و تفسیر مدل میباشد، پرداختیم.در مرحله یادگیری مدل با استفاده از الگوریتمهای متنوع و با در نظر گرفتن ماهیت داده، نظمهای مختلف موجود در دادهها شناسائی میشود. بطور کلی روشهای مختلف کاوش داده را به دو گروه روشهای پیش بینی و روشهای توصیفی طبقه بندی میکنند.
در روشهای پیش بینی از مقادیر بعضی ویژگیها برای پیش بینی کردن مقدار یک ویژگی مشخص استفاده میکنند. این روشها در متون علمی با نام روشهای با ناظر (Supervised Methods ) نیز شناخته میشوند. الگوریتمهای با ناظر از دو مرحله با عنوان مرحله آموزش (یادگیری) و مرحله ارزیابی تشکیل شده اند.
در مرحله آموزش؛ با استفاده از مجموعه دادههای آموزشی مدل ساخته میشود. شکل مدل ساخته شده به نوع الگوریتم یادگیرنده بستگی دارد.
در مرحله ارزیابی؛ از مجموعه دادههای آزمایشی برای اعتبارسنجی و محاسبه دقت مدل ساخته شده استفاده میشود، در واقع از داده هایی که در مرحله آموزش و ساخت مدل؛ الگوریتم این مجموعه دادهها را ندیده است (Previously Unseen Data) استفاده میشود.
برای نمونه روشهای دسته بندی (Classification)، رگرسیون (Regression) و تشخیص انحراف (Anomaly Detection) سه روش یادگیری مدل در داده کاوی با ماهیت پیش بینی هستند.
در روشهای توصیفی همانطور که انتظار داریم الگوهای قابل توصیف از روابط حاکم بر دادهها بدون در نظر گرفتن هر گونه برچسب و یا متغیر خروجی بدست میآید. این روشها در متون علمی با نام روشهای بدون ناظر (Unsupervised Methods) نیز شناخته میشوند. برای نمونه روشهای خوشه بندی (Clustering)، کاوش قوانین انجمنی (Association Rules Mining) و کشف الگوهای ترتیبی (Sequential Pattern Discovery) سه روش یادگیری مدل در داده کاوی با ماهیت توصیفی هستند.
در ادامه به معرفی هر کدام از این روشها میپردازیم:
دسته بندی:
در الگوریتمهای دسته بندی مجموعه داده اولیه به دو مجموعه داده با عنوان مجموعه دادههای آموزشی (Train Dataset) و مجموعه دادههای آزمایشی (Test Dataset) تقسیم میشود. میدانیم هر Case شامل مجموعه ای از Attribute هاست، که یکی از این ویژگیها ویژگی دسته نامیده میشود.در مرحله آموزش؛ مجموعه دادههای آموزشی به یکی از الگوریتمهای دسته بندی داده میشود تا بر اساس سایر ویژگیها برای مقادیر ویژگی دسته، مدل ساخته شود.
پس از ساخت مدل، در مرحله ارزیابی؛ دقت مدل ساخته شده به کمک مجموعه دادههای آزمایشی ارزیابی خواهد شد. در الگوریتمهای دسته بندی از آنجا که ویژگی دسته مربوط به هر Case مشخص است به صورت الگوریتمهای با ناظر محسوب میشوند. بدیهی است که تشخیص بر اساس دسته هایی است که مدل در مرحله آموزش با آنها روبرو شده است؛ بنابراین امکان تشخیص دسته جدید در کاربرد دسته بندی وجود نخواهد داشت.
رگرسیون:
رگرسیون در علوم آمار و شبکههای عصبی بطور وسیعی مورد بررسی و مطالعه قرار میگیرد. پیش بینی مقدار یک متغیر پیوسته بر اساس مقادیر سایر متغیرها بر مبنای یک مدل وابستگی خطی یا غیر خطی رگرسیون نامیده میشود. یک نوع خاصی از رگرسیون، پیش بینی سریهای زمانی (Time Series Prediction) است؛ برای مثال تغییرات قیمت سهام شرکتی را به صورت نمودار داریم؛ میخواهیم ادامه روند این نمودار را برای مدتی مشخص پیش بینی کنیم. در مسائل سریهای زمانی یکی از متغیرهای اصلی زمان میباشد. بدیهی است که رگرسیون لزوماً سری زمانی نیست و همانند دسته بندی کاربرد رگرسیون نیز از نوع پیش بینی با ناظر است و بطور مشابه در رگرسیون هم دو مرحله آموزش و ارزیابی نیز وجود دارد. مثال هایی از رگرسیون میتواند شامل موارد زیر باشد: پیش بینی میزان فروش یک محصول جدید، براساس میزان فروش محصولات گذشته و یا براساس میزان تبلیغات انجام شده و ... همچنین مسائل مربوط به پیش بینی سریهای زمانی از قبیل بورس و ... .تشخیص انحراف:
از کاربردهای متداول تشخیص انحراف، میتوان به کشف کلاهبرداری کارتهای اعتباری (Credit Card Fraud Detection) اشاره کرد. در مواقعی از این کاربرد استفاده میشود که تنها نمونه هایی با یک برچسب یکسان که معمولاً وضعیت نرمال را نشان میدهند در دسترس میباشند و امکان مالکیت بر دادهها با تمامی برچسبهای موجود به دلایل مختلف وجود ندارد. بنابراین چون فقط نمونههای دسته نرمال در اختیار است، الگوریتم برای وضعیت نرمال و با توجه به یک آستانه (Threshold) مشخص مدل را میسازد و هر گونه تخطی از آن آستانه را؛ بعنوان وضعیت غیرنرمال در نظر میگیرد. توجه شود روشهای دسته بندی تنها قادر به شناسائی دسته هایی هستند که در مرحله آموزش، نمونه ای از آنها به الگوریتم ارائه شده است، بنابراین امکان تشخیص هیچ گونه کلاهبرداری توسط روشهای دسته بندی وجود ندارد.خوشه بندی:
در این مسائل از آنجا که بر خلاف دسته بندی هیچ گونه دسته خاصی وجود ندارد، بنابراین براساس معیار شباهت دادهها گروه بندی و خوشه بندی صورت میگیرد. بدین ترتیب Case هایی که بیشترین شباهت را به یکدیگر دارند در یک خوشه قرار میگیرند، به بیان دیگر Caseهای موجود در خوشههای متفاوت کمترین شباهت را به یکدیگر خواهند داشت. بدیهی است که خوشه بندی براساس ویژگی ورودی نمونهها انجام میگیرد و از آنجائی که برای این الگوریتمها ویژگی دسته تعریف نمیشود و Caseها برچسب خاصی ندارند، جزء الگوریتمهای بدون ناظر محسوب میشوند. در واقع هدف در تمامی الگوریتمهای خوشه بندی کمینه کردن فاصله درون خوشه ای (Intra-Cluster Density) و بیشینه نمودن فاصله بین خوشه ای (Inter-Cluster Density) است و عملکرد خوب یک الگوریتم خوشه بندی زمانی محرز میشود که تا حد امکان خوشهها را از یکدیگر دورتر کند و در ضمن Caseهای موجود در یک خوشه بیشترین شباهت را به یکدیگر داشته باشند.کشف قوانین انجمنی:
قوانین وابستگی (انجمنی) اتفاق و وقوع یک شیء را براساس وقوع سایر اشیاء توصیف میکنند، برای مثال در یک سوپر مارکت هدف در کاوش قوانین انجمنی؛ یافتن نظم حاکم بر سبد خرید میباشد، در این کاربرد به ازای هر سبد؛ یک قانون پیدا میشود و بررسی خواهد شد که این قانون در چه تعداد از سبدها صدق میکند و در نهایت یک مجموعه قوانین که در بیشترین تعداد از سبدها صدق میکند به عنوان مجموعه قوانین انجمنی خروجی ارائه میشود. به بیان دیگر در این کاربرد به دنبال پیدا کردن یک مجموعه از قوانین وابستگی هستیم تا براساس آن قوانین بتوانیم نتیجه گیری کنیم وجود کدامیک از مجموعه اشیاء (Item Set) بر وجود چه مجموعه اشیاء دیگری تاثیر گذار است.کشف الگوهای ترتیبی:
در این کاربرد به دنبال کشف الگوهایی هستیم که وابستگیهای ترتیبی محکمی را در میان وقایع مختلف نشان میدهند. این کاربرد مشابه کاوش قوانین انجمنی میباشد با این تفاوت که در کاوش قوانین انجمنی زمان و ترتیب زمانی مطرح نیست، اما در کشف الگوهای ترتیبی زمان و ترتیب اهمیت ویژه ای دارند برای مثال میتوان به دنبالههای تراکنشهای فروش اشاره نمود.منبع: با اندکی تغییر و تلخیص "داده کاوی کاربردی در RapidMiner، انتشارات نیاز دانش"