نظرات مطالب
مدیریت سفارشی سطوح دسترسی کاربران در MVC
سلام
من کل مطالب Mvc 18 و بخش کوکی‌ها را مطالعه کردم اما به دلیل نظرات مختلف متوجه نشدم راه اصولی چیه؟
برای هر کاربر یکسری اطلاعات وجود دارد که میشه در کوکی‌ها ذخیره کرد مثل نام کاربری یا هر چیز دیگه ای که حتی اگر کاربر آنها را تغییر بده مهم نیستند و صرفا جنبه نمایش در صفحات را دارند اما یکسری اطلاعات هست که خیلی مهمه هستند مثل این که این کاربر مدیر هست یا خیر. این اطلاعات یا باید هر بار که نیاز هست از دیتابیس یا هر منبع دیگه ای واکشی بشه ویا در جایی ذخیره بشه که هر وقت خواستیم به اون دسترسی داشته باشیم.
پیش‌تر این نوع اطلاعات و در Session ذخیره می‌کردیم که از دید کاربر به دور بود ، اما برای پردازش موازی و انجام چک لیست تهیه شده بهتره که از Session‌ها استفاده نشه،
خب حالا ذخیره این اطلاعات در کوکی‌ها درسته؟ حتی اگر کد بشن باز خطرناکه ، چرا که یک کاربر اگر بتونه کوکی که مدیر بودن یا نبودن کاربر را مشخص می‌کند را تغییر بده می‌تونه به همه بخش‌ها دسترسی پیدا کنه!
از طرفی صرفا مدیر بودن یا نبودن یک کاربر مطرح نیست ، اطلاعات زیادی  هستند که مهم هستند و ذخیره اون‌ها در  Session میتونه منابع سرور و به خودش مشغول کنه!
روش درست چیه؟ 
نظرات مطالب
چک لیست تهیه یک برنامه ASP.NET MVC
"پوشه Models، از پروژه اصلی حذف شود. یک پروژه class library جدید به نام MyProjectName.Models برای نگهداری ViewModels ایجاد گردد." 
پروژه class library جدید که برای Model درست می‌کنیم [مورد پنجم]، نمیشه اسمبلی  System.Web.Mvc و خیلی رفرنسهای دیگه رو بهش اضافه کرد و میبنده به خطا! فرضاً میخوام AccountModels.cs پیش فرض رو منتقل کنم به class library جدید؛ به مشکل رفرنس‌ها برمبخورم: ویژوال استودیو 2012 و پروژه MVC 4
ضمناً یه سوال دیگه هم از خدمت شما داشتم، بنظرتون درسته بریم سمت MVC 4 یا فعلاً برامون در انتشار پروژه مشکل ایجاد میکنه؟ مثلاً هاست‌های کمی ممکنه دات نت 4.5 یا MVC 4 رو ساپورت کنن و ...
ممنون از زحماتی که میکشید، مخصوصاً از این چک لیست کامل ...
نظرات مطالب
طراحی گردش کاری با استفاده از State machines - قسمت دوم
با تشکر؛
کل بحث جا افتاده است برایم  ولی در مثال BlogPostManager ، کمی غیر قابل درک میباشد که وقتی بحث سطح دسترسی مطرح است ، Guard‌ها چه استفاده ای خواهند داشت؟ منظور بنده این است که وقتی در یک برنامه فرضا Asp.net برای هر یک از Trigger‌ها یک اکشن متد خاص (برای ویرایش فیلد State رکورد) داشته باشیم ، همین چک کردن این مورد که آیا کاربر، نویسنده پست یا مدیر است هم در ابتدای اکشن باید صورت گیرد و اجازه دسترسی به ادامه کار داده نشود(Forbidden)  . اگر برداشت بنده صحیح نیست هم لطفا راهنمایی کنید.
ممنون میشوم بحث را با مثال واقعی تحت وب یا ویندوز مطرح کنید. 
نظرات مطالب
پیاده سازی JSON Web Token با ASP.NET Web API 2.x
- اگر فکر می‌کنید که 2 بار چک کردن به ازای هر درخواست زیاد هست، احتمالا با ASP.NET Identity کار نکردید! در ASP.NET Identity اگر بررسی اعتبار کاربر را به ازای هر درخواست رسیده فعال کنید (بجای مقدار پیش‌فرض چند دقیقه‌ای آن، این مقدار را صفر کنید تا به ازای هر درخواست انجام شود)، همین یک مورد 5 کوئری را شامل می‌شود. برای نمونه در ASP.NET Core 2.X این بررسی‌ها شامل 5 کوئری به جداول AspNetUser, AspNetUserClaims, AspNetUserRoles, AspNetRoles, AspNetRoleClaims هستند.
- 2 بار بررسی بانک اطلاعاتی برای بانک‌های اطلاعاتی امروزی هیچ سرباری ندارد و ضمن اینکه خودشان مباحث کش کردن اطلاعات ویژه‌ای را هم برای کوئری‌های پر استفاده دارند؛ مانند buffer cache در SQL Server که تا حد مصرف حافظه‌ی کل سرور هم می‌تواند پیش رود.
- استفاده از متغیرهای استاتیک و حافظه‌ی سرور برای کش کردن، مقیاس پذیر نیست. در این موارد روش توصیه شده، استفاده از بانک اطلاعاتی Key/Value فوق سریع Redis هست. فقط مشکل تمام کش‌ها، هماهنگ سازی اطلاعات آن‌ها با بانک اطلاعاتی اصلی است که باید مدنظر باشند.
نظرات مطالب
ASP.NET Web API - قسمت اول
روش‌های زیادی برای تامین امنیت در وب API و کار با «کاربران شناسایی شده» وجود دارند. لیست رسمی
از این لیست رسمی، دو مورد معروف آن در سایت جاری بررسی شده:
ASP.NET Identity
Forms authentication
مباحث پایه‌ای این‌ها مشترک است بین MVC و وب فرم‌ها و سایر فناوری‌های مشابه.
نظرات مطالب
ASP.NET Web API - قسمت اول

«مزیت واقعی Web API چیست و چه زمانی پروژه ای رو با Web API شروع می‌کنید ؟»

WCF or ASP.NET Web APIs

به علاوه هدف اصلی Web API و یکپارچگی آن با خصوصا MVC (و بعد وب فرم‌ها) در درجه اول توسعه ActionResultهای پیش فرض MVC است (به همین جهت اول اسم آن ASP.NET است و نه مثلا اندروید):

ASP.NET Web API vs. ASP.NET MVC APIs

مطالب
معرفی برنامه انتخاب واحد
حتما همه‌ی شما با فرآیند انتخاب واحد دانشگاه‌ها آشنا هستید. معمولا دانشجویان سعی می‌کنند، دروسی را انتخاب کنند تا در حداقل تعداد روز‌های هفته، بیشترین تعداد واحد ممکن را بگیرند. اما این کار وقتی که تعداد دروس و اساتید زیاد باشد، مشکل است و باید وقت زیادی  را صرف آن کرد. در نتیجه تصمیم گرفتم تا برنامه‌ای را بنویسم که با گرفتن لیست دروس مورد نظر، تمامی برنامه‌های هفتگی ممکن را نمایش دهد.
   
فناوری‌های استفاده شده:
  
- ASP.NET MVC برای سرور
- AngularJS برای کلاینت
   
الگوریتم پیاده سازی شده:
  
در مورد الگوریتم نیز باید بگویم که من از همان ابتدا ساده‌ترین راه، یعنی تست کردن تمامی حالات ممکن را پیاده سازی کردم. متاسفانه این روش منابع زیادی را مصرف  می‌کند و زمان بر است. البته قطعا می‌توان همین روش را با بهینه سازی‌هایی از جمله انتخاب ساختمان داده‌های مناسب‌تر و تغییراتی در الگوریتم، کاراتر کرد.
همچنین پس از پایان کار، با کمی تحقیق فهمیدم که برای حل این مساله، راه سر راست و ساده ای وجود ندارد. ولی قطعا می‌توان با استفاده از الگوریتم‌های خاصی، راه حل بهتر و بهینه‌تری را پیاده سازی کرد که هدف از به اشتراک گذاری این برنامه همین مساله هست.

برای مثال لینک‌های زیر به توضیح راه‌حل‌هایی برای مسائل مشابه پرداخته‌اند:  
 
دریافت سورس کد
برای دریافت سورس کد برنامه به لینک زیر مراجعه کنید:
   
تصاویری از برنامه:
   

 
 

  

نظرات مطالب
پایان پروژه ASP.NET Ajax Control Toolkit !
با سلام،
تمام این موارد که مبفرمایید درست، من خودم از طرفداران استقاده از jQuery هستم اما یک مسئله برای من هنوز وجود دارد اون هم RAD است. در یکی از کتابخانه های آژاکسی برای asp.net مثل Anthem.Net
این مسئله خیلی خوب رعایت شده و کار توسعه نرم افزار مبنتی بر استفاده از آژاکس به سرعت انجام میشه. این برای من هنوز سواله با jQuery چطور می توان به این سرعت نرم افزار های Full-Ajax را توسعه داد.
مطالب
افزودن یک صفحه‌ی جدید و دریافت و نمایش اطلاعات از سرور به کمک Ember.js
در قسمت قبل با مقدمات برپایی یک برنامه‌ی تک صفحه‌ای وب مبتنی بر Ember.js آشنا شدیم. مثال انتهای بحث آن نیز یک لیست ساده را نمایش می‌دهد. در ادامه همین برنامه را جهت نمایش لیستی از اشیاء JSON دریافتی از سرور تغییر خواهیم داد. همچنین یک صفحه‌ی about را نیز به آن اضافه خواهیم کرد.


پیشنیازهای سمت سرور

- ابتدا یک پروژه‌ی خالی ASP.NET را ایجاد کنید. نوع آن مهم نیست که Web Forms باشد یا MVC.
- سپس قصد داریم مدل کاربران سیستم را توسط یک ASP.NET Web API Controller در اختیار Ember.js قرار دهیم. مباحث پایه‌ای Web API نیز در وب فرم‌ها و MVC یکی است.
مدل سمت سرور برنامه چنین شکلی را دارد:
namespace EmberJS02.Models
{
    public class User
    {
        public int Id { set; get; }
        public string UserName { set; get; }
        public string Email { set; get; }
    }
}
کنترلر Web API ایی که این اطلاعات را در ختیار کلاینت‌ها قرار می‌دهد، به نحو ذیل تعریف می‌شود:
using System.Collections.Generic;
using System.Web.Http;
using EmberJS02.Models;
 
namespace EmberJS02.Controllers
{
    public class UsersController : ApiController
    {
        // GET api/<controller>
        public IEnumerable<User> Get()
        {
            return UsersDataSource.UsersList;
        }
    }
}
در اینجا UsersDataSource.UsersList صرفا یک لیست جنریک ساده از کلاس User است و کدهای کامل آن‌را می‌توانید از فایل پیوست انتهای بحث دریافت کنید.

همچنین فرض بر این است که مسیریابی سمت سرور ذیل را نیز به فایل global.asax.cs، جهت فعال سازی دسترسی به متدهای کنترلر UsersController تعریف کرده‌اید:
using System;
using System.Web.Http;
using System.Web.Routing;
 
namespace EmberJS02
{
    public class Global : System.Web.HttpApplication
    { 
        protected void Application_Start(object sender, EventArgs e)
        {
            RouteTable.Routes.MapHttpRoute(
               name: "DefaultApi",
               routeTemplate: "api/{controller}/{id}",
               defaults: new { id = RouteParameter.Optional }
               );
        }
    }
}

پیشنیازهای سمت کاربر

پیشنیازهای سمت کاربر این قسمت با قسمت «تهیه‌ی اولین برنامه‌ی Ember.js» دقیقا یکی است.
ابتدا فایل‌های مورد نیاز Ember.js به برنامه اضافه شده‌اند:
 PM> Install-Package EmberJS
سپس یک فایل app.js با محتوای ذیل به پوشه‌ی Scripts اضافه شده‌است:
App = Ember.Application.create();
App.IndexRoute = Ember.Route.extend({
    setupController:function(controller) {
        controller.set('content', ['red', 'yellow', 'blue']);
    }
});
و  در آخر یک فایل index.html با محتوای ذیل کار برپایی اولیه‌ی یک برنامه‌ی مبتنی بر Ember.js را انجام می‌دهد:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>
    <script src="Scripts/jquery-2.1.1.js" type="text/javascript"></script>
    <script src="Scripts/handlebars.js" type="text/javascript"></script>
    <script src="Scripts/ember.js" type="text/javascript"></script>
    <script src="Scripts/app.js" type="text/javascript"></script>
</head>
<body>
    <script type="text/x-handlebars" data-template-name="application">
        <h1>Header</h1>
        {{outlet}}
    </script>
    <script type="text/x-handlebars" data-template-name="index">
        Hello,
        <strong>Welcome to Ember.js</strong>!
        <ul>
            {{#each item in content}}
            <li>
                {{item}}
            </li>
            {{/each}}
        </ul>
    </script>
</body>
</html>
تا اینجا را در قسمت قبل مطالعه کرده بودید.
در ادامه قصد داریم به هدر صفحه، دو لینک Home و About را اضافه کنیم؛ به نحوی که لینک Home به مسیریابی index و لینک About به مسیریابی about که صفحه‌ی جدید «درباره‌ی برنامه» را نمایش می‌دهد، اشاره کنند.


تعریف صفحه‌ی جدید About

برنامه‌های Ember.js، برنامه‌های تک صفحه‌ای وب هستند و صفحات جدید در آن‌ها به صورت یک template جدید تعریف می‌شوند که نهایتا متناظر با یک مسیریابی مشخص خواهند بود.
به همین جهت ابتدا در فایل app.js مسیریابی about را اضافه خواهیم کرد:
App.Router.map(function() {
    this.resource('about');
});
به این ترتیب با فراخوانی آدرس about/ در مرورگر توسط کاربر، منابع مرتبط با این آدرس و قالب مخصوص آن، توسط Ember.js پردازش خواهند شد.
بنابراین به صفحه‌ی index.html برنامه مراجعه کرده و صفحه‌ی about را توسط یک قالب جدید تعریف می‌کنیم:
<script type="text/x-handlebars" data-template-name="about">
    <h2>Our about page</h2>
</script>
تنها نکته‌ی مهم در اینجا مقدار data-template-name است که سبب خواهد شد تا به مسیریابی about، به صورت خودکار متصل و مرتبط شود.

در این حالت اگر برنامه را در حالت معمولی اجرا کنید، خروجی خاصی را مشاهده نخواهید کرد. بنابراین نیاز است تا لینکی را جهت اشاره به این مسیر جدید به صفحه اضافه کنیم:
<script type="text/x-handlebars" data-template-name="application">
    <h1>Ember Demo App</h1>
    <ul class="nav">
        <li>{{#linkTo 'index'}}Home{{/linkTo}}</li>
        <li>{{#linkTo 'about'}}About{{/linkTo}}</li>
    </ul>
    {{outlet}}
</script>
اگر از قسمت قبل به خاطر داشته باشید، عنوان شد که قالب ویژه‌ی application به صورت خودکار با وهله سازی Ember.Application.create به صفحه اضافه می‌شود. اگر نیاز به سفارشی سازی آن وجود داشت، خصوصا جهت تعریف عناصری که باید در تمام صفحات حضور داشته باشند (مانند منوها)، می‌توان آن‌را به نحو فوق سفارشی سازی کرد.
در اینجا با استفاده از امکان یا directive ویژه‌ای به نام linkTo، لینک‌هایی به مسیریابی‌های index و about اضافه شده‌اند. به این ترتیب اگر کاربری برای مثال بر روی لینک About کلیک کند، کتابخانه‌ی Ember.js او را به صورت خودکار به مسیریابی about و سپس نمایش قالب مرتبط با آن (قالب about ایی که پیشتر تعریف کردیم) هدایت خواهد کرد؛ مانند تصویر ذیل:


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


دریافت و نمایش اطلاعات از سرور

اکنون که با نحوه‌ی تعریف یک صفحه‌ی جدید و برپایی سیم کشی‌های مرتبط با آن آشنا شدیم، می‌خواهیم صفحه‌ی دیگری را به نام Users به برنامه اضافه کنیم و در آن لیست کاربران ارائه شده توسط کنترلر Web API سمت سرور ابتدای بحث را نمایش دهیم.
بنابراین ابتدا مسیریابی جدید users را به صفحه اضافه می‌کنیم تا لیست کاربران، در آدرس users/ قابل دسترسی شود:
App.Router.map(function() {
    this.resource('about');
    this.resource('users');
});
سپس نیاز است مدلی را توسط فراخوانی Ember.Object.extend ایجاد کرده و به کمک متد reopenClass آن‌را توسعه دهیم:
App.UsersLink = Ember.Object.extend({});
App.UsersLink.reopenClass({
    findAll: function () {
        var users = [];
        $.getJSON('/api/users').then(function(response) {
            response.forEach(function(item) {
                users.pushObject(App.UsersLink.create(item));
            });
        });
        return users;
    }
});
در اینجا متد دلخواهی را به نام findAll اضافه کرده‌ایم که توسط متد getJSON جی‌کوئری، به مسیر /api/users سمت سرور متصل شده و لیست کاربران را از سرور به صورت JSON دریافت می‌کند. در اینجا خروجی دریافتی از سرور به کمک متد pushObject به آرایه کاربران اضافه خواهد شد. همچنین نحوه‌ی فراخوانی متد create مدل UsersLink را نیز در اینجا مشاهده می‌کنید (App.UsersLink.create).

پس از اینکه نحوه‌ی دریافت اطلاعات از سرور مشخص شد، باید اطلاعات این مدل را در اختیار مسیریابی Users قرار داد:
App.UsersRoute = Ember.Route.extend({
    model: function() {
        return App.UsersLink.findAll();
    }
});
 
App.UsersController = Ember.ObjectController.extend({
    customHeader : 'Our Users List'
});
به این ترتیب زمانیکه کاربر به مسیر users/ مراجعه می‌کند، سیستم مسیریابی می‌داند که اطلاعات مدل خود را باید از کجا تهیه نماید.
همچنین در کنترلری که تعریف شده، صرفا یک خاصیت سفارشی و دلخواه جدید، به نام customHeader برای نمایش در ابتدای صفحه تعریف و مقدار دهی گردیده‌است.
اکنون قالبی که قرار است اطلاعات مدل را نمایش دهد، چنین شکلی را خواهد داشت:
<script type="text/x-handlebars" data-template-name="users">
    <h2>{{customHeader}}</h2>
    <ul>
        {{#each item in model}}
        <li>
            {{item.Id}}-{{item.UserName}} ({{item.Email}})
        </li>
        {{/each}}
    </ul>
</script>
با تنظیم data-template-name به users سبب خواهیم شد تا این قالب اطلاعات خودش را از مسیریابی users دریافت کند. سپس یک حلقه نوشته‌ایم تا کلیه عناصر موجود در مدل را خوانده و در صفحه نمایش دهد. همچنین در عنوان قالب نیز از خاصیت سفارشی customHeader استفاده شده‌است:




کدهای کامل این قسمت را از اینجا می‌توانید دریافت کنید:
EmberJS02.zip
نظرات اشتراک‌ها
آیا WPF مرده است؟!
بسته به اینکه شما مرده رو چی در نظر بگیرید مسئله فرق دارد. 
1- اینکه احتما نسخه بعدی وجود ندارد.(احتمالا)
2- جایگزینی بهتری برای آن وجود دارد(100% خیر){ولی احتمالا تا چند وقت دیگر می‌آید زیاد است. چون مایکروسافت قصد دارد تغییراتی را در برنامه‌های توسعه ای خود ایجاد کند که با یک کد برای همه پلت فرم‌ها کد نویسی شود. به نظر من برنامه ای شبیه ویندوز استو با امکانات کامل بزودی جایگزین خواهد شد که با توجه به تکنلوژی Xaml  برای wpf کار‌ها کار سویچ سخت نخواهد شد}