SQL Server CE داخل پروسه برنامه اجرا میشه (و پروسه مجزایی نداره). نسخه LocalDB خارج از پروسه برنامه اما به صورت یک child process اجرا میشه. برنامه وب شما میتونه با هر تعداد فایل sdf مربوط به SQL CE یا فایل mdf بانک اطلاعاتی LocalDB کار کنه (در رشته اتصالی آن AttachDbFileName قابل تعریف هست).
برای مطالعه‌ی این مقاله شما باید به مواردی از قبیل کتابخانه‌ی AngularJs، تعاملات بین کلاینت و سرور و همچنین معماری RESTful تسلط کافی داشته باشید و ما از توضیح و تفصیلی این سرفصل‌ها اجتناب میکنیم.
همانطور که ملاحظه میکنید تمام پروسه‌ی دریافت، در یک خط خلاصه شده است. همچنین می‌بینید که restAngular دارای Promise نیز هست. در تکه کد اول، تمامی userها به صورت Get دریافت می‌شوند. در تکه کد دوم مشاهده میکنید که عملیات درخواست لیست ماشین‌های کاربر چگونه در یک خط خلاصه می‌گردد. حال فرض کنید قصد داشتیم تا این عملیات را با وابستگی http پیاده سازی نماییم. برای این کار باید چندین خط کد را درون یک سرویس جا می‌دادیم و آنگاه از متد سرویس در کنترلر استفاده می‌کردیم.
توجه داشته باشید هنگامیکه یک وابستگی به module اضافه می‌گردد، با حروف کوچک یعنی restangular اضافه می‌گردد؛ اما هنگامیکه به کنترلر اضافه میشود، به صورت Restangular و با R بزرگ اضافه می‌گردد.
در این قسمت قصد داشتیم تا شما را با این کتابخانه کمی آشنا کنیم. در قسمت بعدی سعی میکنیم تا با مثال‌هایی کاربردی، شما را بیشتر با این سرویس خارق العاده آشنا کنیم.
خیلی خوب بپردازیم به اصل مطلب:
Restangular چیست؟
کتابخانه RestAngular بنا به گفته ناشر در مستندات Github آن، یک سرویس توسعه داده شده AngularJs می‌باشد که کدهای نوشته شده‌ی برای پیاده سازی فرآیند‌های Request/Response کلاینت و سرور را به حداقل رسانده است. این فرآیندها در قالب درخواست‌های GET، POST، DELETE و Update صورت می‌پذیرند. این سرویس برای وب اپلیکیشن‌هایی که که داده‌های خود را از APIهای RESTful همانند Microsoft ASP.NET Web API 2 دریافت می‌کنند نیز بسیار کارآمد است.
کد زیر یک فرآیند درخواست GET را نمایش میدهد که در آن از سرویس RestAngular استفاده شده است:
// Restangular returns promises
Restangular.all('users').getList() // GET: /users
.then(function(users) {
// returns a list of users
$scope.user = users[0]; // first Restangular obj in list: { id: 123 }
})
// Later in the code...
// Restangular objects are self-aware and know how to make their own RESTful requests
$scope.user.getList('cars'); // GET: /users/123/cars
// You can also use your own custom methods on Restangular objects
$scope.user.sendMessage(); // POST: /users/123/sendMessage
// Chain methods together to easily build complex requests
$scope.user.one('messages', 123).one('from', 123).getList('unread');
// GET: /users/123/messages/123/from/123/unread در اینجا همچنین قادرید درخواست‌های خود را به صورت سفارشی نیز اعمال کنید (تکه کد سوم) و در آخر مشاهده میکنید که پیچیده‌ترین عملیات‌های درخواست کاربر را می‌توان در یک خط خلاصه نمود. برای نمونه کد آخر یک دستور GET تو در تو را به چه سادگی پیاده سازی کرده است.
وابستگی ها
شروع پروژه
برای شروع پروژه و استفاده از RestAngular، پس از اضافه کردن اسکریپت رفرنس‌ها و وابستگی‌ها (lodash و AngularJs) باید وابستگی restAngular را به صورت زیر به angular.module اضافه نمایید:
// Add Restangular as a dependency to your app
angular.module('your-app', ['restangular']);
// Inject Restangular into your controller
angular.module('your-app').controller('MainCtrl', function($scope, Restangular) {
// ...
}); برخی از متدهای RestAngular
در این بخش قصد داریم تا برخی از پر کاربرد‌ترین متدهای RestAngular را تشریح کنیم:
| نام متد | پارامتر‌های ارسالی | توضیحات |
one | route, id | این متد یک RestAngular object ایجاد میکند که از آدرسی که در route قرار داده شده با id مشخص دریافت میشود. |
all | route | این متد یک RestAngular object که لیستی از المنت هایی را که در آدرس route قرار دارد، دریافت می‌نماید. |
oneUrl | route, url | این متد یک RestAngular object ایجاد میکند که یک المنت از url خاصی را بازگشت میدهد. مانند: Restangular.oneUrl( 'googlers' , 'http://www.google.com/1' ).get(); |
allUrl | route, url | این متد مانند متد قبل است با این تفاوت که یک مجموعه را بازگشت میدهد. |
copy | formElement | این متد یک کپی از المنت‌های یک فرم را ایجاد میکند که ما میتوانیم آنها را تغییر دهیم. |
restangularizeElement | parent,element, route, queryParams | یک المنت جدید را به صورت Restangularize تغییر میدهد. |
restangularizeCollection | parent, element, route, queryParams | یک کالکشن Collection را به صورت Restangularize تغییر میدهد. |
چندی قبل مطلبی را در مورد پردازش فایلهای xml با استفاده از قابلیت Ajax جی کوئری نوشتم. در سایت پی‌سافت، تعدادی فایل XML از شعرا و جملات قصار و امثال آن موجود است (با تقدیر و تشکر از زحمات این عزیزان) که امروز قصد داریم از فایل XML جملات قصار آن یک افزونه jQuery درست کنیم تا آنها را به صورت اتفاقی (random) در صفحه نمایش دهد:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>XML</title>
<script src='jquery-1.3.min.js' type='text/javascript'></script>
<script type="text/javascript">
var ourXml = '';
function parseXml(xml){
ourXml = xml; //for our timer
var i;
var rnd = Math.floor(Math.random() * 130) + 1; //we have 130 entries
for (i = 1; i < 5; i++) //M1 to M4
{
$(xml).find("Ghesaar" + rnd + " > M" + i).each(function(){
$("#output").append($(this).text() +' ');
});
}
}
//ajax loader
$(document).ready(function(){
$.ajax({
type: "GET",
url: "Ghesaar.xml",
dataType: "xml",
success: parseXml
});
});
//timer
window.setInterval(function(){
$("#output").empty().hide();
parseXml(ourXml);
$("#output").fadeIn("slow");
}, 10000);
</script>
</head>
<body>
<span id="output" dir="rtl" style=" "/>
</body>
</html>
همه چیز از قسمت Ajax کد فوق شروع میشود. فایل Ghesaar.xml بارگذاری شده و به تابع parseXml ارسال میشود. در این تابع یک کپی از xml دریافت شده را نگهداری میکنیم تا در تایمری که بعدا جهت نمایش اتفاقی پیام‌ها درست خواهیم کرد، مجبور نشویم مجددا محتویات فایل xml را بارگذاری کنیم.
در تابع parseXml قصد داریم فایل xml ایی با فرمت زیر را پردازش کنیم:
<Ghesaar10>
<M1>ناامیدی، آخرین نتیجه گیری </M1>
<M2>بی خردان است</M2>
<M3>
</M3>
<M4>« ضرب المثل انگلیسی »</M4>
</Ghesaar10>
تا اینجا فقط یکی از جملات قصار در هنگام بارگذاری صفحه نمایش داده خواهند شد. برای تکرار نمایش، از یک تایمر می‌توان کمک گرفت که کد آن‌را در بالا ملاحظه میکنید.
همین!
برای تبدیل آن به یک پلاگین/افزونه جی‌کوئری ، می‌توان به صورت زیر عمل کرد:
$.fn.ghesaar = function(options){
var defaults = {
interval: 1
};
var options = $.extend(defaults, options);
return this.each(function(){
var obj = $(this);
var ourXml = '';
function parseXml(xml){
ourXml = xml; //for our timer
var i;
var rnd = Math.floor(Math.random() * 130) + 1; //we have 130 entries
for (i = 1; i < 5; i++) //M1 to M4
{
$(xml).find("Ghesaar" + rnd + " > M" + i).each(function(){
obj.append($(this).text() + ' ');
});
}
}
//ajax loader
$.ajax({
type: "GET",
url: "Ghesaar.xml",
dataType: "xml",
success: parseXml
});
//timer
window.setInterval(function(){
obj.empty().hide();
parseXml(ourXml);
obj.fadeIn("slow");
}, options.interval * 1000);
});
};
سپس قسمت استاندارد توسعه options اضافه میشود تا بتوان به تابع افزونه خود مقدار interval را پاس کرد تا از این حالت خشک و جمود خارج شود.
کل وقایع افزونه درون تابع زیر رخ میدهد:
return this.each(function(){
...
});
سپس در ابتدای کار شیء this که اشاره‌گری است به شیء انتخاب شده توسط جی‌کوئری را دریافت کرده و هرجایی را که قبلا $("#output") داشتیم، تبدیل به obj میکنیم. (یعنی این مورد هم به انتخاب کاربر خواهد شد)
جهت دریافت مقدار تنظیمی interval هم می‌توان از options.interval استفاده کرد.
به این صورت کد ما تبدیل به یک افزونه جی‌کوئری میشود.
اینبار نحوه‌ی استفاده از افزونه‌ی تولیدی به صورت زیر است: (عدد interval بر اساس ثانیه است)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>XML</title>
<script src='jquery-1.3.min.js' type='text/javascript'></script>
<script src='jquery.ghesaar.js' type='text/javascript'></script>
<script type="text/javascript">
$(document).ready(function(){
$("#output").ghesaar({interval:5});
});
</script>
</head>
<body>
<span id="output" dir="rtl" style=" "/>
</body>
</html>
به صورت ساده:
برای استفاده از آن، سه فایل jquery-1.3.min.js (یا نگارش جدیدتر آن)، jquery.ghesaar.js و Ghesaar.xml را باید آپلود کنید. چند سطری را که در قسمت head صفحه فوق مشاهده می‌نمائید باید اضافه شوند. سپس یک span یا div را جهت نمایش این جملات قصار به هر جایی از ساختار صفحه خود که علاقمند بودید اضافه کنید (id آن مهم است و در قسمت نمایش جملات قصار مورد جستجو قرار می‌گیرد).
فایلهای این پروژه را از اینجا دریافت کنید.
در مطالب قبل کنترلر‌ها و viewها مورد بحث قرار گرفتند. در این پست در نظر داریم یکی از ویژگی‌های دیگر AngularJs به نام مسیر یابی (Routing) را مورد بحث قرار دهیم.
یکی از ویژگی‌های برنامه‌های تک صفحه ای عدم Reload شدن صفحات است ،بر خلاف برنامه‌های وب چند صفحه ای که برای نمایش صفحه ای دیگر ، باید از صفحه ای به صفحه ای دیگر منتقل شد و عمل Reload هم به طبع نیز اتفاق می‌افتد.
در قسمت اول این سری مقالات ، مزایای برنامه‌های وب تک صفحه ای SPA به صورت کاملتری بیان شده است. در ادامه ما قصد داریم برنامه‌ی وب خود را به صفحات مختلف تقسیم کنیم و سپس با استفاده از امکان مسیریابی موجود در AngularJs آن صفحات را که هر کدام به کنترلری مجزا مقید شده اند، در صفحه‌ی اصلی خود بارگزاری کنیم. همچین استفاده از مسیریابی موجود، میتواند به ما در مدیریت بهتر صفحات کمک فراوانی بکند.
به تصویر زیر دقت کنید :
در تصویر بالا دو مسیر با آدرس‌های : ShowPage1/ و ShowPage2/ تعریف شده است که هر کدام به یک view مشخص و یک Controller برای مدیریت آن اشاره میکند.
زمانی که ما از تزریق وابستگی‌ها در AngularJs استفاده میکنیم و یک شیء را به کنترلر تزریق میکنیم، Angular توسط Injector$ سعی در پیدا کردن وابستگی مربوطه و سپس تزریق آن به کنترلر را انجام میدهد. برای استفاده از امکان مسیریابی Route ، ما نیز باید از پروایدر مخصوص آن برای تزریق استفاده کنیم. در Angular مسیر‌های برنامه توسط پروایدری به نام routeProvider$ شناسایی میشود که خدمات مسیریابی را به ما ارائه میدهد. این سرویس به ما کمک میکند تا بتوانیم اتصال بین کنترلر ها، ویوها و آدرس URL جاری مرورگرها را به آسانی برقرار کنیم.
بهتر است کار را شروع کنیم . یک فایل JS ایجاد و سپس محتویات زیر را در آن قرار دهید :
var myFirstRoute = angular.module('myFirstRoute', []);
myFirstRoute.config(['$routeProvider',
function($routeProvider) {
$routeProvider.
when('/pageOne', {
templateUrl: 'templates/page_one.html',
controller: 'ShowPage1Controller'
}).
when('/pageTwo', {
templateUrl: 'templates/page_two.html',
controller: 'ShowPage2Controller'
}).
otherwise({
redirectTo: '/pageOne'
});
}]);
myFirstRoute.controller('ShowPage1Controller', function($scope) {
$scope.message = 'Content of page-one.html';
});
myFirstRoute.controller('ShowPage2Controller', function($scope) {
$scope.message = 'Content of page-two.html';
}); در کدهای بالا ابتدا یک ماژول تعریف کرده ایم و سپس توسط ()config. تنظیمات مربوط به مسیریابی را انجام داده ایم. با استفاده از متدهای when. و otherwise. میتوانیم مسیرها را تعریف کنیم. برای هر مسیر دو پارامتر وجود دارد که اولین پارامتر نام مسیر و دومین پارامتر شامل 2 قسمت میشود که templateUrl آن آدرسی که باز خواهد شد و controller نیز نام کنترلری که ویو را مدیریت میکند.
توسط otherwise میتوانیم مسیر پیشفرض را نیز تعریف کنیم تا درصورتی که مسیری با آدرس‌های بالای آن مطابقت نداشت به این آدرس منتقل شود.
در قطعه کد بالا همچنین دو مسیر با نام‌های pageOne/ و pageTwo/ تعریف کرده ایم که هر کدام به ترتیب به Viewهای : templates/page_one.html و templates/page_two.html مرتبط شده اند. همچنین دو کنترلر برای مدیریت ویوها نیز تعریف شده است.
زمانی که ما آدرس http://appname/#pageOne را در نوار آدرس مرورگر وارد میکنیم، Angular به صورت اتوماتیک آدرس URL را با تنظیماتی که ما در اینجا تعریف کرده ایم مطابقت میدهد و در صورت وجود چنین آدرسی ، view مربوطه را بارگزاری میکند و در این مثال نیز مطابق با تنظیمات بالا، صفحه‌ی templates/page_one.html برای ما بارگزاری و سپس کنترلر ShowPage1Controller را فراخوانی میکند ، جایی که ما منطق کار را در آن قرار میدهیم.
محتویات فایل main.html :
<body ng-app="app">
<div>
<div>
<div>
<ul>
<li><a href="#pageOne"> Show page one </a></li>
<li><a href="#pageTwo"> Show page two </a></li>
</ul>
</div>
<div>
<div ng-view></div>
</div>
</div>
</div>
<script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.7/angular.min.js"></script>
<script src="app.js"></script>
</body> در قطعه کد بالا دو لینک تعریف شده است که ویژگی href از علامت هش و نام صفحه تشکیل شده است. یکی از چیزهایی که شایان ذکر است ، دایرکتیو ng-view است. مکانی برای بارگزاری صفحات در آن.
ما میتوانیم این تگ را به سه شکل زیر نیز استفاده کنیم :
<div ng-view></div> .. <ng-view></ng-view> .. <div class="ng-view"></div>
محتویات صفحه templates/page_one.html :
<h2>Page One</h2>
{{ message }} محتویات صفحه templates/page_two.html :
<h2>Page Two</h2>
{{ message }} حال اگر پروژه را اجرا کنید و به کنسول مرور گر خود نگاه کنید متوجه میشوید که مسیریاب از مسیر پیشفرض استفاده کرده است و صفحه‌ی page_one.html را به صورت ایجکسی فراخوانی کرده است :
و اگر روی لینک Show Page two کلیک کنید ، صفحه‌ی page_two.html نیز به صورت ایجکسی فراخوانی میشود.
دوباره بر روی لینک Show page one کلیک کنید. بله. هیچ درخواستی به سمت سرور ارسال نشد و صفحه‌ی page_one.html به خوبی نمایش داده شد. یکی از مزیت‌های سیستم مسیریابی قابلیت کش کردن صفحات است تا در صورت فراخوانی مجدد، درخواستی به سمت سرور ارسال نشود و خیلی سریع به شما نمایش داده شود.
مثال این مطلب : RouteExample.zip
ادامه دارد ...
از Sandbox برای ساخت و انتشار وب پارت هایی استفاده میشود که نیاز به مداخله مدیریتی (administrative intervention) وجود ندارد. به این معنی که شما میتوانید وب پارت خود را در محل شیرپوینت و هاست آن یا با استفاده از زیر ساخت‌های Cloud و دور از هاست آن ، بارگذاری کرده و انتشار دهید.
هر Solution که برای Sandbox ایجاد میشود ، در یک گالری خاص به نام Solution Gallery در Site Collection مربوطه ایجاد میشود و تمام این solutionها می‌توانند قعال یا غیر فعال شوند .
برای استفاده از این مزایا باید سرویس Microsoft SharePoint Foundation User Code Service فعال باشد .
استفاده از Sandbox Solution نیازمند 3 چیز است :
1 - User Code Service یا SPUCHostService.exe : این سرویس وظیفه مدیریت کدهای Sandbox روی سرور و میزبانی درخواست‌های Sandbox به سرور را دارد.
2 - Sandbox Worker Process یا SPUCWorkerProcess.exe : این سرویس برای مدیریت پردازش کدهای اجرایی Sandbox استفاده میشود خصوصا در مورارد امنیتی (فرض کنید درون کد حلقه بی نهایتی وجود داشته باشد. اگر بار اجرایی آن بر روی w3wp.exe باشد ، باعث متوقف شدن کارکرد تمام پروسه میشود. بار این مسئولیت بر دوش SPUCWorkerProcess.exe می‌باشد )
3 - Sandbox Worker Process Proxy یا SPUCWorkerProcessProxy.exe : این سرویس برای اجرای کدهای Client Object Model در sandbox استفاده میشود.
می توانید ارتباط پردازه‌های فوق را در نمودار زیر مشاهد کنید :
با توجه به این توضیحات به دلیل استفاده از Sandbox می‌پردازیم :
1 - sandbox Solutionها امن هستند.
2 - sandbox Solutionها می‌توانند مانیتور شوند.
3 - sandbox Solutionها حداقل تاثیر را روی هم دارند.
4 - sandbox Solutionها عملیات I/O کمی روی فایلهای سیستمی دارند
5 - sandbox Solutionها امکان debugging دارند
6 - sandbox Solutionها امکان توسعه ، انتشار و به روز رسانی دارند
7 - sandbox Solutionها امکان تعریف Policy برای CAS ایجاد میکند (Code Access Security برای قابل اطمینان ساخت کد ها)
8 - sandbox Solutionها امکان اعتبار سنجی به کمک کلاس SPSolutionValidator را میدهد.
9 - sandbox Solutionها امکان تعریف SLA های مختلف را میدهد.
چه قسمت هایی توسط Sandbox Solution پشتیبانی میشود :
هنگام ایجاد یک پروژه از نوع sandbox در ویژوال استودیو ، یکسری امکانات از برنامه نویس سلب میشود و محدودیت‌های برای استفاده از کلاس‌ها برای وی اعمال میشود .موارد زیر ، از جمله مواردی هستند که توسعه دهنده میتواند از آنها در sandbox استفاده کند :
اسفاده محدود از لیست‌ها ، کار با Web Templateها و ویژگی‌های آنها ، Content Typeها و فیلد‌ها ، ماژول‌ها و فایل‌ها ، وب پارت‌های مشتق شده از کلاس WebPart ، برخی Event Receiverها ، بعضی از Custom Action و چرخه‌های کاری . و از مواردی که نمی‌توان در sandbox استفاده کرد می‌توان به ویژگی‌های موجود در Web Application ، ویژگی‌های موجود در Farm و Timer job ، استفاده از عملیات I/O و استفاده از ADO و برخی کلاس‌های دیگر در دات نت اشاره کرد .
مدیران سایت می‌توانند Solutionها را مونیتور کنند و برای Resource Point هایی که در یک روز مصرف می‌کنند Quota تعریف کنند .پیش فرض این مقدار 300 Resource Point در روز است .
هر solution در هنگام deploy شدن جهت معتبر بودن چک میشود و سپس منتشر شود. در صورتی که Valid نباشد ، خطایی به برنامه نویس نشان میدهد.
در انتها اشاره ای هم به استفاده از STSADM یا Powershell برای deploy کردن solution میکنم که توسط دستورات زیر قابل اجراست :
Add-SPSolution c:\code\SharePointProject2\bin\debug\SharePointProject2.wsp
stsadm –o addsolution –name SharePointProject2.wsp
همانطور که پسوند فایلهای solution را مشاهده میکند wsp هستند که اگر آنها را به cab تغییر نام دهید میتوانید محتویات آنها را مشاهده کنید
در قسمت قبل سناریوهای مختلف مرتبط با طراحی موجودیت‌های سیستم را بررسی کردیم. در این قسمت به طراحی DTOهای متناظر با موجودیت‌ها به همراه اعتبارسنج‌های مرتبط و در نهایت به پیاده سازی سرویس‌های CRUD آنها خواهیم پرداخت.
قراردادها، مفاهیم و نکات اولیه
- برخلاف بسیاری از طراحی‌های موجود، بر فراز هر موجودیت اصلی (منظور AggregateRoot) باید یک DTO که از این پس با عنوان Model از آنها یاد خواهیم کرد، تعریف شود.
- هیچ تراکنشی برای موجودیت‌های فرعی یا همان Detailها نخواهیم داشت. این موجودیت‌ها در تراکنش موجودیت اصلی مرتبط به آن مدیریت خواهند شد.
- هر Commandای که قرار است مرتبط با یک موجودیت اصلی در سیستم انجام پذیرد، باید از منطق تجاری آن موجودیت عبور کند و نباید با دور زدن منطق تجاری، از طرق مختلف تغییراتی بر آن موجودیت اعمال شود. (موضوع مهمی که در ادامه مطلب جاری تشریح خواهد شد)
- ویوهای مختلفی از یک موجودیت می‌توان انتظار داشت که ویو پیشفرض آن در CrudService تدارک دیده شده است. برای سایر موارد نیاز است در سرویس مرتبط، متدهای Read مختلفی را پیاده‌سازی کنید.
- با اعمال اصل CQS، متدهای ثبت و ویرایش در کلاس سرویس پایه CRUD، بعد از انجام عملیات مربوطه، Id و RowVersion مدل ورودی و هچنین Id و TrackingState موجودیت‌های فرعی وابسته، مقداردهی خواهند شد و نیاز به انجام یک Query دیگر و بازگشت آن به عنوان خروجی متدها نبوده است. به همین دلیل خروجی این متدها صرفا Result ای می‌باشد که نشان از امکان Failure بودن انجام آنها می‌باشد که با اصل مذکور در تضاد نمی‌باشد.
- ورودی متدهای Read شما که در اکثر موارد نیاز به مهیا کردن خروجی صفحهبندی شده دارند، باید از نوع PagedQueryModel و یا اگر همچنین نیاز به جستجوی پویا براساس فیلدهایی موجود در ReadModel مرتبط دارید، باید از نوع FilteredPagedQueryModel باشد. متدهای الحاقی برای اعمال خودکار این صفحهبندی و جستجوی پویا در نظر گرفته شده است. همچنین خروجی آنها در اکثر موارد از نوع IPagedQueryResult خواهد بود. اگر نیاز است تا جستجوی خاصی داشته باشید که خصوصیتی متناظر با آن فیلد در مدل Read وجود ندارد، لازم است تا از این QueryModelهای مطرح شده، ارث‌بری کرده و خصوصیت اضافی مدنظر خود را تعریف کنید. بدیهی است که اعمال جستجوی این موارد خاص به عهده توسعه دهنده می‌باشد.
- عملیات ثبت، ویرایش و حذف، برای کار بر روی لیستی از وهله‌های Model، طراحی شده‌اند. این موضوع در بسیاری از دومین‌ها قابلیت مورد توجهی می‌باشد.
- رخداد متناظر با عملیات CUD مرتبط با هر موجودیت اصلی، به عنوان یکسری نقاط قابل گسترش (Extensibility Point) در اختیار سایر بخش‌های سیستم می‌باشد. این رخدادها درون تراکنش جاری Raise خواهند شد؛ از این جهت امکان اعمال یکسری Rule جدید از سمت سایر موءلفه‌های سیستم موجود می‌باشد.
- برخلاف بسیاری از طراحی‌های موجود، قصد ایجاد لایه انتزاعی برفراز EF Core به منظور رسیدن به Persistence Ignorance را ندارم. بنابراین امروز بسته DNTFrameworkCore.EntityFramework آن آماده می‌باشد. اگر توسعه دهنده‌ای قصد یکپارچه کردن این زیرساخت را با سایر ORMها یا Micro ORMها داشته باشد، میتواند Pull Request خود را ارسال کند.
- خبر خوب اینکه هیچ وابستگی به AutoMapper به منظور نگاشت مابین موجودیت‌ها و مدل‌های متناظر آنها، در این زیرساخت وجود ندارد. با پیاده سازی متدهای MapToModel و MapToEntity میتوانید از کتابخانه Mapper مورد نظر خودتان استفاده کنید؛ یا به صورت دستی این کار را انجام دهید. بعد از چند سال استفاده از AutoMapper، این روزها خیلی اعتقادی به استفاده از آن ندارم.
- هیچ وابستگی به FluentValidation به منظور اعتبارسنجی ورودی متدها یا پیاده‌سازی قواعد تجاری، در این زیرساخت وجود ندارد. شما امکان استفاده از Attributeهای اعتبارسنجی توکار، پیاده سازی IValidatableObject توسط مدل یا در موارد خاص به منظور پیاده سازی قواعد تجاری پیچیده، پیاده سازی IModelValidator را دارید. با این حال برای یکپارچگی با این کتابخانه محبوب، میتوانید بسته نیوگت DNTFrameworkCore.FluentValidation را نصب کرده و استفاده کنید.
- با اعمال الگوی Template Method در پیاده سازی سرویس CRUD پایه، از طریق تعدادی متد با پیشوندهای Before و After متناظر با عملیات CUD میتوانید در فرآیند انجام آنها نیز دخالت داشته باشید؛ به عنوان مثال: BeforeEditAsync یا AfterCreateAsync
- باتوجه به اینکه در فرآیند انجام متدهای CUD، یکسری Event هم Raise خواهند شد و همچنین در خیلی از موراد شاید نیاز به فراخوانی SaveChange مرتبط با UnitOfWork جاری باشد، لذا مطمئن‌ترین راه حل برای این قضیه و حفظ ثبات سیستم، همان استفاده از تراکنش محیطی می‌باشد. از این جهت متدهای مذکور با TransactionAttribute نیز تزئین شده‌اند که برای فعال سازی این مکانیزم نیاز است تا TransactionInterceptor مربوطه را به سیستم معرفی کنید.
- ValidationInterceptor موجود در زیرساخت، در صورتیکه خروجی متد از نوع Result باشد، خطاهای ممکن را در قالب یک شی Result بازگشت خواهد داد؛ در غیر این صورت یک استثنای ValidationException پرتاب میشود که این مورد هم توسط GlobalExceptionFilter مدیریت خواهند شد و در قالب یک BadRequest به کلاینت ارسال خواهد شد.
- در سناریوهای Master-Detail، قرارداد این است که Detailها به همراه Master متناظر واکشی خواهند شد و در زمان ثبت و یا ویرایش هم همه آنها به همراه Master متناظر خود به سرور ارسال خواهند شد.
نکته مهم: همانطور که اشاره شد، در سناریوهای Master-Detail باید تمامی Detailها به سمت سرور ارسال شوند. در این صورت سناریویی را در نظر بگیرید که قرار است کاربر در front-office سیستم امکان حذف یک قلم از اقلام فاکتور را داشته باشد؛ این درحالی است که در back-office و در منطق تجاری اصلی، ما جایی برای حذف یک تک قلم ندیده‌ایم و کلا منطق و قواعد تجاری حاکم بر فاکتور را زیر سوال می‌برد. چرا که ممکن است یکسری قواعد تجاری متناسب با دومین، بر روی لیست اقلام یک فاکتور در زمان ذخیره سازی وجود داشته باشند که با حذف یک تک قلم از یک مسیر فرعی، کل فاکتور را در حالت نامعتبری برای ذخیره سازی‌های بعدی قرار دهد. در این موارد باید API شما یک DTO سفارشی را دریافت کند که شامل شناسه قلم فاکتور و شناسه فاکتور می‌باشد. سپس با استفاده از شناسه فاکتور و سرویس متناظر، آن را واکشی کرده و از لیست قلم‌های InvoiceModel، آن قلم را با TrackingState.Deleted علامت‌گذاری کنید. همچنین باید توجه داشته باشید که برروی فیلدهای موجود در جداول مرتبط با موجودیت‌های Detail، محدودیت‌های دیتابیسی از جمله Unique Constraint و ... را اعمال نکنید؛ مگر اینکه میدانید و دقیقا مطمئن باشید عملیات حذف اقلام، قبل از عملیات ثبت اقلام جدید رخ میدهد (این موضوع نیاز به توضیح و شبیه سازی شرایط خاص آن را دارد که در صورت نیاز می‌توان در مطلب جدایی به آن پرداخت).
پیاده سازی و بررسی تعدادی سرویس فرضی
برای شروع لازم است بسته‌های نیوگت زیر را نصب کنید:
PM> Install-Package DNTFrameworkCore -Version 1.0.0 PM> Install-Package DNTFrameworkCore.EntityFramework -Version 1.0.0
مثال اول: پیاده‌سازی سرویس یک موجودیت ساده بدون نیاز به ReadModel
گام اول: طراحی Model متناظر
[LocalizationResource(Name = "SharedResource", Location = "DNTFrameworkCore.TestAPI")]
public class BlogModel : MasterModel<int>, IValidatableObject
{
public string Title { get; set; }
[MaxLength(50, ErrorMessage = "Maximum length is 50")]
public string Url { get; set; }
public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
if (Title == "BlogTitle")
{
yield return new ValidationResult("IValidatableObject Message", new[] {nameof(Title)});
}
}
}
گام دوم: پیاده‌سازی اعتبارسنج مستقل
در صورت نیاز به اعتبارسنجی پیچیده برای مدل متناظر، میتوانید با استفاده از دو روش زیر به این هدف برسید:
1- استفاده از کتابخانه DNTFrameworkCore.FluentValidation
public class BlogValidator : FluentModelValidator<BlogModel>
{
public BlogValidator(IMessageLocalizer localizer)
{
RuleFor(b => b.Title).NotEmpty()
.WithMessage(localizer["Blog.Fields.Title.Required"]);
}
}
2- پیاده‌سازی IModelValidator یا ارث‌بری از کلاس ModelValidator پایهpublic class BlogValidator : ModelValidator<BlogkModel>
{
public override IEnumerable<ModelValidationResult> Validate(BlogModel model)
{
yield return new ModelValidationResult(nameof(BlogkModel.Title), "Validation from IModelValidator");
}
} گام سوم: پیاده‌سازی سرویس متناظر
public interface IBlogService : ICrudService<int, BlogModel>
{
} پیاده سازی واسط بالا
public class BlogService : CrudService<Blog, int, BlogModel>, IBlogService
{
public BlogService(CrudServiceDependency dependency) : base(dependency)
{
}
protected override IQueryable<BlogModel> BuildReadQuery(FilteredPagedQueryModel model)
{
return EntitySet.AsNoTracking().Select(b => new BlogModel
{Id = b.Id, RowVersion = b.RowVersion, Url = b.Url, Title = b.Title});
}
protected override Blog MapToEntity(BlogModel model)
{
return new Blog
{
Id = model.Id,
RowVersion = model.RowVersion,
Url = model.Url,
Title = model.Title,
NormalizedTitle = model.Title.ToUpperInvariant() //todo: normalize based on your requirement
};
}
protected override BlogModel MapToModel(Blog entity)
{
return new BlogModel
{
Id = entity.Id,
RowVersion = entity.RowVersion,
Url = entity.Url,
Title = entity.Title
};
}
} برای این چنین موجودیت‌هایی، بازنویسی همین 3 متد کفایت میکند؛ دو متد MapToModel و MapToEntity برای نگاشت مابین مدل و موجودیت مورد نظر و متد BuildReadQuery نیز برای تعیین نحوه ساخت کوئری ReadPagedListAsync پیشفرض موجود در CrudService به عنوان متد Read پیشفرض این موجودیت. باکمترین مقدار کدنویسی و با کیفیت قابل قبول، عملیات CRUD یک موجودیت ساده، تکمیل شد.
مثال دوم: پیاده سازی سرویس یک موجودیت ساده با ReadModel و FilteredPagedQueryModel متمایز
گام اول: طراحی Model متناظر
[LocalizationResource(Name = "SharedResource", Location = "DNTFrameworkCore.TestAPI")]
public class TaskModel : MasterModel<int>, IValidatableObject
{
public string Title { get; set; }
[MaxLength(50, ErrorMessage = "Validation from DataAnnotations")]
public string Number { get; set; }
public string Description { get; set; }
public TaskState State { get; set; } = TaskState.Todo;
public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
if (Title == "IValidatableObject")
{
yield return new ValidationResult("Validation from IValidatableObject");
}
}
} public class TaskReadModel : MasterModel<int>
{
public string Title { get; set; }
public string Number { get; set; }
public TaskState State { get; set; } = TaskState.Todo;
public DateTimeOffset CreationDateTime { get; set; }
public string CreatorUserDisplayName { get; set; }
}
گام دوم: پیاده‌سازی اعتبارسنج مستقل
public class TaskValidator : ModelValidator<TaskModel>
{
public override IEnumerable<ModelValidationResult> Validate(TaskModel model)
{
if (!Enum.IsDefined(typeof(TaskState), model.State))
{
yield return new ModelValidationResult(nameof(TaskModel.State), "Validation from IModelValidator");
}
}
}
گام سوم: پیاده‌سازی سرویس متناظر public interface ITaskService : ICrudService<int, TaskReadModel, TaskModel, TaskFilteredPagedQueryModel>
{
}
مدل جستجو و صفحهبندی سفارشی
public class TaskFilteredPagedQueryModel : FilteredPagedQueryModel
{
public TaskState? State { get; set; }
}
پیاده سازی واسط ITaskService با استفاده از AutoMapper
public class TaskService : CrudService<Task, int, TaskReadModel, TaskModel, TaskFilteredPagedQueryModel>,
ITaskService
{
private readonly IMapper _mapper;
public TaskService(CrudServiceDependency dependency, IMapper mapper) : base(dependency)
{
_mapper = mapper ?? throw new ArgumentNullException(nameof(mapper));
}
protected override IQueryable<TaskReadModel> BuildReadQuery(TaskFilteredPagedQueryModel model)
{
return EntitySet.AsNoTracking()
.WhereIf(model.State.HasValue, t => t.State == model.State)
.ProjectTo<TaskReadModel>(_mapper.ConfigurationProvider);
}
protected override Task MapToEntity(TaskModel model)
{
return _mapper.Map<Task>(model);
}
protected override TaskModel MapToModel(Task entity)
{
return _mapper.Map<TaskModel>(entity);
}
} به عنوان مثال در کلاس بالا برای نگاشت مابین مدل و موجودیت، از واسط IMapper کتابخانه AutoMapper استفاده شده‌است و همچنین عملیات جستجوی سفارشی در همان متد BuildReadQuery برای تولید کوئری متد Read پیشفرض، قابل ملاحظه می‌باشد.
مثال سوم: پیاده‌سازی سرویس یک موجودیت اصلی به همراه تعدادی موجودیت فرعی وابسته (سناریوهای Master-Detail)
گام اول: طراحی Modelهای متناظر
public class UserModel : MasterModel
{
public string UserName { get; set; }
public string DisplayName { get; set; }
public string Password { get; set; }
public bool IsActive { get; set; }
public ICollection<UserRoleModel> Roles { get; set; } = new HashSet<UserRoleModel>();
public ICollection<PermissionModel> Permissions { get; set; } = new HashSet<PermissionModel>();
public ICollection<PermissionModel> IgnoredPermissions { get; set; } = new HashSet<PermissionModel>();
} مدل بالا متناظر است با موجودیت کاربر سیستم، که به یکسری گروه کاربری متصل می‌باشد و همچنین دارای یکسری دسترسی مستقیم بوده و یا یکسری دسترسی از او گرفته شده‌است. مدل‌های Detail نیز از قرارداد خاصی پیروی خواهند کرد که در ادامه مشاهده خواهیم کرد.
public class PermissionModel : DetailModel<int>
{
public string Name { get; set; }
} به عنوان مثال PermissionModel بالا از DetailModel جنریک‌ای ارث‌بری کرده است که دارای Id و TrackingState نیز می‌باشد.
public class UserRoleModel : DetailModel<int>
{
public long RoleId { get; set; }
} شاید در نگاه اول برای گروه‌های کاربری یک کاربر کافی بود تا یک لیست ساده از long را از کلاینت دریافت کنیم. در این صورت نیاز است تا برای تمام موجودیت‌های سیستم که چنین شرایط مشابهی را دارند، عملیات ثبت، ویرایش و حذف متناظر با تک تک Detailها را دستی مدیریت کنید. روش فعلی خصوصا برای سناریوهای منفصل به مانند پروژه‌های تحت وب، پیشنهاد میشود.
گام دوم: پیاده سازی اعتبارسنج مستقل
public class UserValidator : FluentModelValidator<UserModel>
{
private readonly IUnitOfWork _uow;
public UserValidator(IUnitOfWork uow, IMessageLocalizer localizer)
{
_uow = uow ?? throw new ArgumentNullException(nameof(uow));
RuleFor(m => m.DisplayName).NotEmpty()
.WithMessage(localizer["User.Fields.DisplayName.Required"])
.MinimumLength(3)
.WithMessage(localizer["User.Fields.DisplayName.MinimumLength"])
.MaximumLength(User.MaxDisplayNameLength)
.WithMessage(localizer["User.Fields.DisplayName.MaximumLength"])
.Matches(@"^[\u0600-\u06FF,\u0590-\u05FF,0-9\s]*$")
.WithMessage(localizer["User.Fields.DisplayName.RegularExpression"])
.DependentRules(() =>
{
RuleFor(m => m).Must(model =>
!CheckDuplicateDisplayName(model.DisplayName, model.Id))
.WithMessage(localizer["User.Fields.DisplayName.Unique"])
.OverridePropertyName(nameof(UserModel.DisplayName));
});
RuleFor(m => m.UserName).NotEmpty()
.WithMessage(localizer["User.Fields.UserName.Required"])
.MinimumLength(3)
.WithMessage(localizer["User.Fields.UserName.MinimumLength"])
.MaximumLength(User.MaxUserNameLength)
.WithMessage(localizer["User.Fields.UserName.MaximumLength"])
.Matches("^[a-zA-Z0-9_]*$")
.WithMessage(localizer["User.Fields.UserName.RegularExpression"])
.DependentRules(() =>
{
RuleFor(m => m).Must(model =>
!CheckDuplicateUserName(model.UserName, model.Id))
.WithMessage(localizer["User.Fields.UserName.Unique"])
.OverridePropertyName(nameof(UserModel.UserName));
});
RuleFor(m => m.Password).NotEmpty()
.WithMessage(localizer["User.Fields.Password.Required"])
.When(m => m.IsNew, ApplyConditionTo.CurrentValidator)
.MinimumLength(6)
.WithMessage(localizer["User.Fields.Password.MinimumLength"])
.MaximumLength(User.MaxPasswordLength)
.WithMessage(localizer["User.Fields.Password.MaximumLength"]);
RuleFor(m => m).Must(model => !CheckDuplicateRoles(model))
.WithMessage(localizer["User.Fields.Roles.Unique"])
.When(m => m.Roles != null && m.Roles.Any(r => !r.IsDeleted));
}
private bool CheckDuplicateUserName(string userName, long id)
{
var normalizedUserName = userName.ToUpperInvariant();
return _uow.Set<User>().Any(u => u.NormalizedUserName == normalizedUserName && u.Id != id);
}
private bool CheckDuplicateDisplayName(string displayName, long id)
{
var normalizedDisplayName = displayName.NormalizePersianTitle();
return _uow.Set<User>().Any(u => u.NormalizedDisplayName == normalizedDisplayName && u.Id != id);
}
private bool CheckDuplicateRoles(UserModel model)
{
var roles = model.Roles.Where(a => !a.IsDeleted);
return roles.GroupBy(r => r.RoleId).Any(r => r.Count() > 1);
}
} به عنوان مثال در این اعتبارسنج بالا، قواعدی از جمله بررسی تکراری بودن نام‌کاربری و از این دست اعتبارسنجی‌ها نیز انجام شده است. نکته حائز اهمیت آن متد CheckDuplicateRoles می‌باشد:
private bool CheckDuplicateRoles(UserModel model)
{
var roles = model.Roles.Where(a => !a.IsDeleted);
return roles.GroupBy(r => r.RoleId).Any(r => r.Count() > 1);
} با توجه به «نکته مهم» ابتدای بحث، model.Roles، شامل تمام گروه‌های کاربری متصل شده به کاربر می‌باشند که در این لیست برخی از آنها با TrackingState.Deleted، برخی دیگر با TrackingState.Added و ... علامت‌گذاری شده‌اند. لذا برای بررسی یکتایی و عدم تکرار در این سناریوها نیاز به اجری پرس‌و‌جویی بر روی دیتابیس نمی‌باشد. بدین منظور، با اعمال یک شرط، گروه‌های حذف شده را از بررسی خارج کرده‌ایم؛ چرا که آنها بعد از عبور از منطق تجاری، حذف خواهند شد.
گام سوم: پیاده‌سازی سرویس متناظر
public interface IUserService : ICrudService<long, UserReadModel, UserModel>
{
} public class UserService : CrudService<User, long, UserReadModel, UserModel>, IUserService
{
private readonly IUserManager _manager;
public UserService(CrudServiceDependency dependency, IUserManager manager) : base(dependency)
{
_manager = manager ?? throw new ArgumentNullException(nameof(manager));
}
protected override IQueryable<User> BuildFindQuery()
{
return base.BuildFindQuery()
.Include(u => u.Roles)
.Include(u => u.Permissions);
}
protected override IQueryable<UserReadModel> BuildReadQuery(FilteredPagedQueryModel model)
{
return EntitySet.AsNoTracking().Select(u => new UserReadModel
{
Id = u.Id,
RowVersion = u.RowVersion,
IsActive = u.IsActive,
UserName = u.UserName,
DisplayName = u.DisplayName,
LastLoggedInDateTime = u.LastLoggedInDateTime
});
}
protected override User MapToEntity(UserModel model)
{
return new User
{
Id = model.Id,
RowVersion = model.RowVersion,
IsActive = model.IsActive,
DisplayName = model.DisplayName,
UserName = model.UserName,
NormalizedUserName = model.UserName.ToUpperInvariant(),
NormalizedDisplayName = model.DisplayName.NormalizePersianTitle(),
Roles = model.Roles.Select(r => new UserRole
{Id = r.Id, RoleId = r.RoleId, TrackingState = r.TrackingState}).ToList(),
Permissions = model.Permissions.Select(p => new UserPermission
{
Id = p.Id,
TrackingState = p.TrackingState,
IsGranted = true,
Name = p.Name
}).Union(model.IgnoredPermissions.Select(p => new UserPermission
{
Id = p.Id,
TrackingState = p.TrackingState,
IsGranted = false,
Name = p.Name
})).ToList()
};
}
protected override UserModel MapToModel(User entity)
{
return new UserModel
{
Id = entity.Id,
RowVersion = entity.RowVersion,
IsActive = entity.IsActive,
DisplayName = entity.DisplayName,
UserName = entity.UserName,
Roles = entity.Roles.Select(r => new UserRoleModel
{Id = r.Id, RoleId = r.RoleId, TrackingState = r.TrackingState}).ToList(),
Permissions = entity.Permissions.Where(p => p.IsGranted).Select(p => new PermissionModel
{
Id = p.Id,
TrackingState = p.TrackingState,
Name = p.Name
}).ToList(),
IgnoredPermissions = entity.Permissions.Where(p => !p.IsGranted).Select(p => new PermissionModel
{
Id = p.Id,
TrackingState = p.TrackingState,
Name = p.Name
}).ToList()
};
}
protected override Task BeforeSaveAsync(IReadOnlyList<User> entities, List<UserModel> models)
{
ApplyPasswordHash(entities, models);
ApplySerialNumber(entities, models);
return base.BeforeSaveAsync(entities, models);
}
private void ApplySerialNumber(IEnumerable<User> entities, IReadOnlyList<UserModel> models)
{
var i = 0;
foreach (var entity in entities)
{
var model = models[i++];
if (model.IsNew || !model.IsActive || !model.Password.IsEmpty() ||
model.Roles.Any(a => a.IsNew || a.IsDeleted) ||
model.IgnoredPermissions.Any(p => p.IsDeleted || p.IsNew) ||
model.Permissions.Any(p => p.IsDeleted || p.IsNew))
{
entity.SerialNumber = _manager.NewSerialNumber();
}
else
{
//prevent include SerialNumber in update query
UnitOfWork.Entry(entity).Property(a => a.SerialNumber).IsModified = false;
}
}
}
private void ApplyPasswordHash(IEnumerable<User> entities, IReadOnlyList<UserModel> models)
{
var i = 0;
foreach (var entity in entities)
{
var model = models[i++];
if (model.IsNew || !model.Password.IsEmpty())
{
entity.PasswordHash = _manager.HashPassword(model.Password);
}
else
{
//prevent include PasswordHash in update query
UnitOfWork.Entry(entity).Property(a => a.PasswordHash).IsModified = false;
}
}
}
} در سناریوهای Master-Detail نیاز است متد دیگری تحت عنوان BuildFindQuery را نیز بازنویسی کنید. این متد برای بقیه حالات نیاز به بازنویسی نداشت؛ چرا که یک تک موجودیت واکشی می‌شد و خبری از موجودیت‌های Detail نبود. در اینجا لازم است تا روش تولید کوئری FindAsyn رو بازنویسی کنیم تا جزئیات دیگری را نیز واکشی کنیم. به عنوان مثال در اینجا Roles و Permissions کاربر نیز Include شده‌اند.
نکته: بازنویسی BuildFindQuery را شاید بتوان با روش‌های دیگری هم مانند تزئین موجودیت‌های وابسته با یک DetailOfAttribute و مشخص کردن نوع موجودیت اصلی، نیز جایگزین کرد.
متدهای MapToModel و MapToEntity هم به مانند قبل پیاده‌سازی شده‌اند. موضوع دیگری که در برخی از سناریوها پیش خواهد آمد، مربوط است به خصوصیتی که در زمان ثبت ضروری می‌باشد، ولی در زمان ویرایش اگر مقدار داشت باید با اطلاعات موجود در دیتابیس جایگزین شود؛ مانند Password و SerialNumber در موجودیت کاربر. برای این حالت می‌توان از متد BeforeSaveAsync بهره برد؛ به عنوان مثال برای SerialNumber:
private void ApplySerialNumber(IEnumerable<User> entities, IReadOnlyList<UserModel> models)
{
var i = 0;
foreach (var entity in entities)
{
var model = models[i++];
if (model.IsNew || !model.IsActive || !model.Password.IsEmpty() ||
model.Roles.Any(a => a.IsNew || a.IsDeleted) ||
model.IgnoredPermissions.Any(p => p.IsDeleted || p.IsNew) ||
model.Permissions.Any(p => p.IsDeleted || p.IsNew))
{
entity.SerialNumber = _manager.NewSerialNumber();
}
else
{
//prevent include SerialNumber in update query
UnitOfWork.Entry(entity).Property(a => a.SerialNumber).IsModified = false;
}
}
} در اینجا ابتدا بررسی شده‌است که اگر کاربر، جدید می‌باشد، غیرفعال شده است، کلمه عبور او تغییر داده شده است و یا تغییراتی در دسترسی‌ها و گروه‌های کاربری او وجود دارد، یک SerialNumber جدید ایجاد کند. در غیر این صورت با توجه به اینکه برای عملیات ویرایش، به صورت منفصل عمل میکنیم، نیاز است تا به شکل بالا، از قید این فیلد در کوئری ویرایش، جلوگیری کنیم.
نکته: متد BeforeSaveAsync دقیقا بعد از ردیابی شدن وهله‌های موجودیت توسط Context برنامه و دقیقا قبل از UnitOfWork.SaveChange فراخوانی خواهد شد.
برای بررسی بیشتر، پیشنهاد میکنم پروژه DNTFrameworkCore.TestAPI موجود در مخزن این زیرساخت را بازبینی کنید.
شیوه‌های متعددی رو برای نگهداری نکات مختلفی که ضمن کار یادمی‌گرفتم، تست کردم از جمله نوشتن در کاغذهای مخصوص فیش و استفاده از OneNote و بعضی از نرم افزارهای فیش نگاری و ... همه روش‌هایی که گفته شد به نوعی یک یادداشت برداری کاغذی ولی به سبک دیجیتال هستند نه خیلی بیشتر که معمولا خسته کننده هستند و کم نتیجه و عمدتا پاسخگوی نیازهای جدید نیستند
پس از مدتی استفاده از این شیوه‌ها به این نتیجه رسیدم که یک ویکی شخصی کم دردسر برای خودم راه اندازی کنم. نرم‌افزارهای سورس باز مختلفی رو تست کردم و علیرغم برخی کاستی‌ها به همان نرم افزاری رسیدم که سایت معظم ویکی پیدیا از اون استفاده میکنه یعنی نرم افزار MediaWiki که از اینجا میتونید دانلودش کنید
در مدیاویکی شخصی خودتون به صورت کاملا لوکالی، میتونید فیش‌ها، یادداشت‌ها، صفحات وبی و مقالات متعددی رو ایجاد و ویرایش کنید و به یکدیگر و به سایت‌های اینترنتی پیوند بدید. همه صفحات ویکی شما میتونند با همدیگه به شکل درون متنی پیوند برقرار کنند و شبکه‌ای از مفاهیم مرتبط به هم تشکیل بدند. همچنین برای هر صفحه میشه از دسته‌بندی و کلمات کلیدی که توسط خودتون تعریف میشه برای طبقه‌بندی استفاده کرد
نصب و راه‌اندازی اون بسیار ساده است و کافیه مثلا فقط نرم افزار WAMP -Windows Apache Mysql PHP- رو به عنوان راه انداز وب سرور داخلی نصب کنید و ...
ربطش به برنامه نویسی
یکی از کاربردهایی که میشه برای این شیوه در نظر گرفت، نگهداری و به اشتراک گذاری دانش افراد مثلا در یک تیم برنامه‌نویسی است که پس از مدتی استفاده از اون باعث تولید یک مجموعه ارزشمند از تجربیات و دانش افراد میشه و افراد تازه کار میتونن در تجربیات بقیه شریک بشن و هرکاری فقط توسط یک نفر تجربه میشه و سایرین اونو استفاده میکنن و نیازی نیست که همه اونو تجربه کنن یا به قولی دوباره چرخ رو اختراع کنن
در مورد افزونه YSlow افزونه Firebug فایرفاکس پیشتر صحبت شد. این افزونه پس از آنالیز یک سایت، پیشنهاداتی را نیز جهت بهبود سرعت، ارائه میدهد.
همانطور که در شکل بالا مشخص است، عناصری مانند css و js ، قسمت expires اشان (تاریخ منقضی شدن کش آنها در سمت کلاینت) خالی است و پیشنهاد داده که به هر کدام از این عناصر، هدر مخصوص مشخص سازی مدت زمان کش شدن در سمت کلاینت اضافه شود.
ASP.Net در مورد کش کردن اطلاعات صفحات پویا به اندازه‌ی کافی امکانات در اختیار برنامه نویس قرار میدهد اما در مورد اضافه کردن این هدر جهت یک فایل css غیر پویا شاید نتوان مطلب خاصی را یافت.
در IIS7 امکانات ویژه‌ای برای این منظور در نظر گرفته شده که نحوه استفاده از آن در ASP.Net به صورت زیر است:
فایل وب کانفیگ سایت را باز کرده و به قسمت system.webServer چند سطر زیر را اضافه کنید:
<staticContent>
<clientCache httpExpires="Sun, 29 Mar 2020 00:00:00 GMT" cacheControlMode="UseExpires" />
</staticContent>
این مورد فقط مختص به IIS7 است و بر روی نگارش‌های پایین‌تر کار نمی‌کند.
با این کار، تاریخ منقضی شدن هر آنچه که توسط موتور ASP.net سرو نمی‌شود به سال 2020 تنظیم خواهد شد. (کلیه محتوای غیرپویای سایت، اعم از تصاویر، فایلهای css ، js و غیره)
پس از این تنظیم مجددا YSlow را اجرا کرده و Performance Grade ایی را که نمایش میدهد بررسی نمائید.
بدیهی است اگر یکی از فایلهای css یا js شما تغییر کند، کلاینت، اطلاعات جدیدی را تا سال 2020 دریافت نمی‌کند. برای حل این مشکل یک کوئری استرینگ ساده به انتهای لینک مربوط به css یا js خود اضافه کنید تا URL جدید با URL قبلی آن یکسان نباشد (این کوئری استرینگ تاثیری روی محتوای ایستای ما ندارد). به این صورت این آدرس جدید، مجددا دریافت شده و تا سال 2020 کش خواهد شد.
نکته:
اعمال تنظیم فوق، در IIS7 ویندوز سرور 2008 مجاز است؛ اما در IIS7 ویندوز ویستا قفل شده است و قابل override نیست. برای تغییر آن، فایل زیر را پیدا کنید:
open %systemroot%\System32\inetsrv\config\applicationHost.config
<section name="staticContent" overrideModeDefault="Deny" />
<section name="staticContent" overrideModeDefault="Allow" />
مآخذ:
YSlow: Add expires header to images in IIS 7
IIS7: How to set cache control for static content?
با سلام - تا اونجایی که من میدونم در مورد بانک‌های اطلاعاتی در لینوکس باید از mysql به جای sqlserver استفاده کرد.
آیا راهی وجود داره که وب سایت طراحی شده با asp.net mvc که دارای بانک اطلاعاتی sqlserver هست رو در سرور لینوکس راه اندازی کرد؟
سلام
من از سیستم معمولی وب فرم برای تشخیص هویت در mvc 4 استفاده کردم. اما به یه مشکل جالب برخوردم.
اپلیکیشین وب من روی شبکه داخلی کار میکنه و هر کس با نام کاربری خودش وارد میشه و کار میکنه.
بعد از لوگین ریدایرکت میکنم و در صفحه مقصد در هنگام User.Identity.IsAuthenticated همیشه false برمیگردونه و نمی‌تونم وارد شم. با هیچکدوم از مرورگرها وارد نمیشه ولی با فایرفاکس میتونم وارد شم!
من بدین صورت کد لوگین رو نوشتم:
if (Membership.ValidateUser(UserName, Password))
{
FormsAuthentication.RedirectFromLoginPage(UserName, true);
return true;
}
دوستان نظرشون چیه؟ مشکل از چی میتونه باشه؟ فایرفاکس چه خاصیتی داره که میتونه لوگین کنه؟ اما با IE و Chrome و safari امتحان کردم نشد.
در وب کانفیگ هم اینجوری تنظیم کردم
<authentication mode="Forms" >
<forms loginUrl="~/Account/Login"
protection="All"
timeout="30"
name="myAppCookie"
path="/"
requireSSL="false"
slidingExpiration="true"
cookieless="UseCookies"
enableCrossAppRedirects="false" />
</authentication>
<membership >
<providers>
<clear />
<add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider"
connectionStringName="ApplicationServices" enablePasswordRetrieval="false"
enablePasswordReset="true" requiresQuestionAndAnswer="false"
requiresUniqueEmail="false" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" applicationName="myApp " />
</providers>
</membership>
<profile>
<providers>
<clear />
<add name="AspNetSqlProfileProvider" type="System.Web.Profile.SqlProfileProvider"
connectionStringName="ApplicationServices" applicationName="myApp " />
</providers>
</profile>
<roleManager enabled="true">
<providers>
<clear />
<add name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider"
connectionStringName="ApplicationServices" applicationName="myApp "/>
<add name="AspNetWindowsTokenRoleProvider"
type="System.Web.Security.WindowsTokenRoleProvider" applicationName="myApp " />
</providers>
</roleManager>