بله. همانطور که در مقدمه بحث عنوان شد، WebMatrix.Data.dll هم لایهای است روی ADO.NET . مابقی هم به همین صورت؛ به این جهت که از پیشرفتهای زبانهای دات نتی استفاده کنند. زمانیکه ADO.NET ارائه شد نه Generics وجود داشت، نه LINQ نه قابلیتهای پویای زبان و نه ...
نظرات مطالب
آشنایی با NHibernate - قسمت پنجم
در کامنتهای فوق توضیح دادم. این توضیحات مربوط به نگارش 2 بود. الان نگارش 3 را که دریافت کنید LINQ با آن یکپارچه است و نیازی به دریافت پروایدر کمکی نیست و پروایدر قدیمی هم منسوخ شده و دیگر ادامه نخواهد یافت.
نظرات مطالب
آشنایی با NHibernate - قسمت پنجم
سلام جناب آقای نصیری
ممنون از آموزشهای بسیار عالیتون
لینک دریافت پروایدر LINQ که گذاشتید موقع دانلود error میده می تونید لینک دیگه ای معرفی کنید
ممنون از آموزشهای بسیار عالیتون
لینک دریافت پروایدر LINQ که گذاشتید موقع دانلود error میده می تونید لینک دیگه ای معرفی کنید
نظرات مطالب
خلاصهای از LINQ to XML
برای تکمیل بحث با اجازه آقای نصیری این لینک هم من اضافه می کنم که قابلیت های خارق العاده LINQ رو برای کار با XML نشون می ده :
http://windowsclient.net/learn/video.aspx?v=6895
موفق باشید.
http://windowsclient.net/learn/video.aspx?v=6895
موفق باشید.
پاسخ به بازخوردهای پروژهها
دریافت ایندکس ردیف جاری جدول هر صفحه
زمانیکه با LINQ کار میکنید، شماره هر ردیف را به این صورت میتوانید پیدا کنید:
var myResult = someTable.Select((r, i) => new { Row = r, Index = i });
MySQL قادر به ایندکس کردن ستونهای JSON نمیباشد. برای حل این مشکل میتوانیم از generated columnها استفاده کنیم. منظور، ایجاد ستونهایی است که مقدارشان به صورت محاسبه شده و براساس ستونهای دیگر میباشد؛ به عنوان مثال جدول کاربران زیر را در نظر بگیرید:
برای کوئری گرفتن full name در حالت معمول میتوانیم از تابع CONCAT استفاده کنیم:
اما توسط generated columns میتوانیم یک ستون را به جدول کاربران اضافه کنیم که مقدارش براساس دو فیلد first_name و last_name محاسبه و مقدار دهی شود:
همانطور که مشاهده میکنید از سینتکس GENERATE ALWAYS برای ایجاد generated column استفاده شدهاست. در MySQL دو نوع generated column وجود دارد: STORED و VIRTUAL؛ تفاوت آنها نیز در نحوه ذخیرهسازی است. در حالت VIRTUAL که حالت پیشفرض است، مقادیر ذخیره نمیشوند؛ بلکه به صورت on the fly محاسبه و در خروجی نمایش داده خواهند شد. در حالیکه نوع STORED همانطور که از نامش پیداست، ذخیره خواهند شد؛ در نتیجه قابلیت ایندکسگذاری را دارد. برای تعیین نوع ستون نیز سینتکس آن اینگونه خواهد بود:
در ادامه یک generated column را برای جدول productsMetadata تعیین خواهیم کرد:
از آنجائیکه هیچ ایندکسی برای این فیلد جدید لحاظ نشده است، MySQL کل ردیفها را برای یافتن id موردنظر جستجو خواهد کرد. این مورد را میتوانید با دستور EXPLAIN نیز مشاهده کنید:
CREATE TABLE `Users` ( id int NOT NULL AUTO_INCREMENT, first_name VARCHAR(255) NOT NULL, last_name VARCHAR(255) NOT NULL, email VARCHAR(255) NOT NULL, gender ENUM('Male','Female') NOT NULL, PRIMARY KEY (`id`) )
SELECT *, CONCAT(first_name, '', last_name) AS full_name FROM Users;
ALTER TABLE Users ADD COLUMN full_name TEXT GENERATED ALWAYS AS (CONCAT(first_name, ' ', last_name))
ALTER TABLE Users ADD COLUMN full_name TEXT GENERATED ALWAYS AS (CONCAT(first_name, ' ', last_name)) STORED
همچنین لازم به ذکر است که حین استفاده از generated columns باید نکات زیر را در نظر داشته باشید:
- generated columnsها نمیتوانند شامل subqueries, parameters, variables, stored procedure, user-defined functions باشند.
- بر روی یک ستون generated نمیتوان AUTO_INCREMENT گذاشت یا اینکه از یک ستون AUTO_INCREMENT برای محاسبه generated column استفاده کرد.
- کلیدهای خارجیای که در generated columnsها استفاده میشوند، قابلیت استفاده از CASCADE, SET NULL, or SET DEFAULT as ON UPDATE or ON DELETE را نخواهند داشت.
ALTER TABLE productMetadata ADD COLUMN id INT GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(data, '$.id'))) STORED NOT NULL
بنابراین زمانیکه یک مقدار JSON را ذخیره میکنیم، کلید اصلی از path تعیین شده استخراج شده و به عنوان یک computed column برای این جدول تعیین خواهد شد. در ادامه میتوانید جزئیات تغییر فوق را مشاهده کنید:
اکنون کوئری زیر را در نظر بگیرید که رکوردی با آیدی ۱ را بازیابی خواهد کرد:
SELECT data ->> "$.description.shortDescription" FROM productMetadata WHERE id = 1;
همانطور که مشاهده میکنید مقدار type به ALL تنظیم شدهاست؛ همچنین مقدار rows نیز تعداد ردیفهای جدول است که در اینجا ۱۳ ردیف دیتا را داریم. قاعدتاً با اضافه شدن دیتای جدید به جدول، جستجو نیز به مراتب کندتر خواهد شد. بنابراین با اضافه کردن ایندکس میتوانیم مشکل این کند بودن را رفع کنیم. به همین جهت در ادامه یک ایندکس را براساس ستون id که یک generated column است ایجاد خواهیم کرد:
CREATE INDEX idx_json_data ON productMetadata (id);
اکنون اگر یکبار دیگر کوئری قبلی را اجرا کنیم، خواهیم دید که تعداد rows به ۱ و همچنین type به ref ست شدهاند:
دقیقا این کاری بود که من قبلا انجام داده بودم ولی مشکلی که پیش میآمد این بود که مثلا اگر در یک ارسال بایستی 200 پیامک ارسال گردد قبل از اینکه ارسال این 200 پیامک به اتمام برسد زمان اجرا به پایان رسیده و تابع execute مجددا فراخوانی میشود و از انجایی که هنوز وضعیت این رکورد در دیتابیس به ارسال شده تغییر پیدا نکرده مجددا این 200 پیامک ارسال میگردد. این مشکل حتی زمانی که از حلقه for هم استفاده نمیشود وجود دارد و در تعداد ارسال بالا به مشکل میخورد .
در زیر کدی که برای ارسال استفاده نموده ام را قرار دادم.
با تشکر از شما
در زیر کدی که برای ارسال استفاده نموده ام را قرار دادم.
با تشکر از شما
namespace SchedulerDemo.Jobs { using System; using System.Linq; using System.IO; using Quartz; using System.Collections.Generic; using System.Configuration; [PersistJobDataAfterExecution] [DisallowConcurrentExecution] public class SendJob : IJob { public void Execute(IJobExecutionContext context) { using (var db = new DALModel.DALEntities()) { byte status = (byte)AllEnums.Sms.Status.InProgress; var item = db.SentBoxes.Where(p => p.Status == status && p.IsDeleted==false && p.UserInfo.IsDeleted==false && p.HasTime == true && p.SendInTime == false && p.SendDateX <= DateTime.Now).OrderBy(p=>p.Id).FirstOrDefault(); Cls_SMS.ClsSend sms_Batch = new Cls_SMS.ClsSend(); if (item != null) { decimal smsCount = 0; if (item.UserInfo.CalculateType == Convert.ToByte(AllEnums.FinancialTransaction.CalculationUnit.Message)) { smsCount = Convert.ToDecimal(Function.GetSmsCount(item.Price, item.UserId)); } else { smsCount = Convert.ToDecimal(item.CorrectCount); } decimal adminCredit = Function.GetAdminCreditLink1000(); if (adminCredit != -1 && adminCredit >= smsCount) { if ((item.UserInfo.Credit - (item.UserInfo.LowCredit)) >= item.Price) { item.SendInTime = true; db.SaveChanges(); string numberList = item.NumberList; int position = item.NumberList.LastIndexOf(','); numberList = item.NumberList.Substring(0, position); List<string> receivers_List = new List<string>(); receivers_List = (numberList).Split(',').ToList(); string[] ret2 = new string[2]; string[] DestAdd = new string[receivers_List.Count]; DestAdd = receivers_List.ToArray(); ret2 = sms_Batch.SendSMS_Batch(item.Message, DestAdd, item.UserInfoSenderNumber.AllNumber.Number, ConfigurationManager.AppSettings["SmsUserNameLink1000"], ConfigurationManager.AppSettings["SmsPasswordLink1000"], ConfigurationManager.AppSettings["SmsIPAddressLink1000"], ConfigurationManager.AppSettings["SmsCompanyLink1000"], false, item.Id); var sentBoxUpdate = db.SentBoxes.FirstOrDefault(p => p.Id == item.Id); sentBoxUpdate.Status = Convert.ToByte(AllEnums.Sms.Status.Send); sentBoxUpdate.FinancialTransactionId = db.FinancialTransactions.Where(p => p.UserId == item.UserId).Max(p => p.Id); if (ret2 != null) { sentBoxUpdate.RetValue0 = ret2[0]; sentBoxUpdate.RetValue1 = ret2[1]; } db.SaveChanges(); } else { byte statusFailedForAccount = (byte)AllEnums.Sms.Status.FailedForAccount; item.SendInTime = true; item.Status = statusFailedForAccount; item.FailedCount = item.CorrectCount; item.FailedList = item.NumberList; db.SaveChanges(); } } else { byte statusFaildForError = (byte)AllEnums.Sms.Status.FaildForError; item.SendInTime = true; item.Status = statusFaildForError; item.FailedCount = item.CorrectCount; item.FailedList = item.NumberList; db.SaveChanges(); } } } } } } namespace SchedulerDemo.Interfaces { public interface IScheduleSend { void RunSendSms(); } } namespace SchedulerDemo.Jobs { using System; using Quartz; using Quartz.Impl; using SchedulerDemo.Interfaces; using SchedulerDemo.Jobs; public class SendSchedule : IScheduleSend { public void RunSendSms() { DateTimeOffset startTime = DateBuilder.FutureDate(2, IntervalUnit.Second); IJobDetail job = JobBuilder.Create<SendJob>() .WithIdentity("jobSendSmsInTime") .Build(); ITrigger trigger = TriggerBuilder.Create() .WithIdentity("triggerSendSmsInTime") .StartAt(startTime) .WithSimpleSchedule(x => x.WithIntervalInMinutes(5).RepeatForever()) .Build(); ISchedulerFactory sf = new StdSchedulerFactory(); IScheduler sc = sf.GetScheduler(); sc.ScheduleJob(job, trigger); sc.Start(); } } }
در قسمت قبل با مفاهیمی مانند fakes ،stubs ،dummies و mocks آشنا شدیم و در اولین آزمایشی که نوشتیم، کار تدارک dummies را به عنوان پارامترهای سازندهی سرویس مورد بررسی، توسط کتابخانهی Moq و اشیاء <Mock<T آن انجام دادیم؛ پارامترهایی که ذکر آنها ضروری بودند، اما در آزمایش ما مورد استفاده قرار نمیگرفتند. در این قسمت میخواهیم کار تدارک stubs را توسط کتابخانهی Moq انجام دهیم؛ به عبارتی میخواهیم مقادیر بازگشتی از متدهای اشیاء Mock شده را تنظیم و کنترل کنیم.
تنظیم خروجی متدهای اشیاء Mock شده
در انتهای قسمت قبل، آزمون واحد متد Accept، با شکست مواجه شد؛ چون متد Validate استفاده شده، همواره مقدار false را بر میگرداند:
در ادامه شیء Mock از نوع IIdentityVerifier را طوری تنظیم خواهیم کرد که بر اساس یک applicant مشخص، خروجی true را بازگشت دهد:
در اینجا ابتدا کار با شیء Mock شده آغاز میشود. سپس باز ذکر متد Setup، میتوان به صورت strongly typed به تمام متدهای اینترفیس IIdentityVerifier دسترسی یافت و آنها را تنظیم کرد. تا اینجا متد مدنظر را از اینترفیس IIdentityVerifier انتخاب کردیم. سپس توسط متد Returns، خروجی دقیقی را برای آن مشخص میکنیم.
به این ترتیب زمانیکه در متد Process کلاس LoanApplicationProcessor کار به بررسی هویت کاربر میرسد، اگر متد Validate آن با اطلاعات applicant مشخصی که تنظیم کردیم، یکی بود، متغیر isValidIdentity که حاصل بررسی identityVerifier.Validate_ است، به true مقدار دهی خواهد شد. برای بررسی آن یک break-point را در این نقطه قرار داده و آزمون واحد را در حالت دیباگ اجرا کنید.
البته هرچند اگر اکنون نیز این آزمایش واحد را مجددا بررسی کنیم، باز هم با شکست مواجه خواهد شد؛ چون مرحلهی بعدی بررسی، کار با سرویس ICreditScorer است که هنوز تنظیم نشدهاست:
فعلا این قسمت از code را comment میکنیم تا آزمایش واحد ما با موفقیت به پایان برسد. در قسمت بعدی کار تنظیم مقادیر خواص را انجام داده و این قسمت از code را نیز پوشش خواهیم داد.
تطابق با آرگومانهای متدها در متدهای Mock شده
با تنظیمی که انجام دادیم، اگر متد Validate به مشخصات شیء applicant مشخص ما برسد، خروجی true را بازگشت میدهد. برای مثال اگر در این بین تنها نام شخص تغییر کند، خروجی بازگشت داده شده همان false خواهد بود. اما اگر این نام برای ما اهمیتی نداشت و قصد داشتیم با تمام نامهای متفاوتی که دریافت میکند، بازهم خروجی true را بازگشت دهد، میتوان از قابلیت argument matching کتابخانهی Moq و کلاس It آن استفاده کرد:
()<It.IsAny<string در اینجا به این معنا است که هر نوع ورودی رشتهای، قابل قبول بوده و دیگر متد Validate بر اساس یک نام مشخص، مورد بررسی قرار نمیگیرد. IsAny یک متد جنریک است و بر اساس نوع آرگومان مدنظر که برای مثال در اینجا رشتهای است، نوع جنریک آن مشخص میشود.
بدیهی است در این حالت باید سایر پارامترها دقیقا با مقادیر مشخص شده تطابق داشته باشند و اگر این موارد نیز اهمیتی نداشتند، میتوان به صورت زیر عمل کرد:
در این حالت متد Validate، صرفنظر از ورودهای آن، همواره مقدار true را باز میگرداند.
البته این نوع تنظیمات بیشتر برای حالات غیرمشخص مانند استفادهاز Guidها به عنوان پارامترها و مقادیر، میتواند مفید باشد.
تقلید متدهایی که پارامترهایی از نوع out دارند
اگر به اینترفیس IIdentityVerifier که در قسمت قبل معرفی شد دقت کنیم، یکی از متدهای آن دارای خروجی از نوع out است:
این متد خروجی ندارد، اما خروجی اصلی آن از طریق پارامتر isValid، دریافت میشود. برای استفادهی از آن، متد Process کلاس LoanApplicationProcessor را به صورت زیر تغییر میدهیم:
در این حالت اگر آزمون واحد متد Accept را بررسی کنیم، با شکست مواجه خواهد شد. به همین جهت تنظیمات Mocking این متد را به صورت زیر تعریف میکنیم:
برای تنظیم متدهایی که پارامترهایی از نوع out دارند، باید ابتدا مقدار مورد انتظار را مشخص کرد. بنابراین مقدار آنرا به true در اینجا تنظیم کردهایم. سپس در متد Setup، متدی تنظیم شدهاست که پارامتری از نوع out دارد. در آخر نیازی به ذکر متد Returns نیست؛ چون خروجی متد از نوع void است.
اکنون اگر مجددا آزمون واحد متد Accept را اجرا کنیم، با موفقیت به پایان میرسد.
تقلید متدهایی که پارامترهایی از نوع ref دارند
اگر به اینترفیس IIdentityVerifier که در قسمت قبل معرفی شد دقت کنیم، یکی از متدهای آن دارای خروجی از نوع ref است:
این متد خروجی ندارد، اما خروجی اصلی آن از طریق پارامتر status، دریافت میشود و نوع آن به صورت زیر تعریف شدهاست تا وضعیت تعیین هویت شخص را مشخص کند:
برای استفادهی از آن، متد Process کلاس LoanApplicationProcessor را به صورت زیر تغییر میدهیم تا بتوان به نمونهی وهله سازی شدهی status دسترسی یافت:
در این حالت اگر آزمون واحد متد Accept را بررسی کنیم، با شکست مواجه خواهد شد. به همین جهت تنظیمات Mocking این متد را به صورت زیر تعریف میکنیم که با متدهای out دار مقداری متفاوت است:
ابتدا در سطح کلاس آزمایش واحد یک delegate را تعریف میکنیم:
این delegate دقیقا دارای همان پارامترهای متد Validate در حال بررسی است.
اکنون روش استفادهی از آن برای برپایی تنظیمات mocking متد Validate از نوع ref دار به صورت زیر است:
تنظیمات قسمت Setup آن آشنا است؛ بجز قسمت ref آن که از It.Ref<IdentityVerificationStatus>.IsAny استفاده کردهاست. چون نوع پارامتر، ref است، باید از It.Ref استفاده کرد که به نوع بازگشت داده شدهی IdentityVerificationStatus اشاره میکند. IsAny آن هم هر نوع ورودی از این دست را میپذیرد.
سپس متد جدید Callback را مشاهده میکنید. توسط آن میتوان یک قطعه کد سفارشی را زمانیکه متد Mock شدهی Validate ما اجرا میشود، اجرا کرد. در اینجا delegate سفارشی ما اجرا شده و مقدار status را بر میگرداند؛ اما در ادامه این مقدار را به یک new IdentityVerificationStatus سفارشی تنظیم میکنیم که در آن مقدار خاصیت Passed، مساوی true است.
اکنون اگر مجددا آزمون واحد متد Accept را اجرا کنیم، با موفقیت به پایان میرسد.
تنظیم متدهای Mock شده جهت بازگشت null
فرض کنید اینترفیسی به صورت زیر تعریف شدهاست:
و اگر بخواهیم برای آن آزمون واحدی را بنویسیم که خروجی این متد به صورت مشخصی نال باشد، میتوان تنظیمات Moq آنرا به صورت زیر انجام داد:
در اینجا دو روش را برای بازگشت نال ملاحظه میکنید:
الف) میتوان همانند سابق متد Returns را ذکر کرد که نال بر میگرداند؛ اما با این تفاوت که حتما باید نوع آرگومان جنریک آنرا نیز بر اساس خروجی متد، مشخص کرد.
ب) کتابخانهی Moq، مقدار خروجی پیشفرض تمام متدهایی را که یک نوع ارجاعی را باز میگردانند، نال درنظر میگیرد و عملا نیازی به ذکر متد Returns در اینجا نیست.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: MoqSeries-02.zip
تنظیم خروجی متدهای اشیاء Mock شده
در انتهای قسمت قبل، آزمون واحد متد Accept، با شکست مواجه شد؛ چون متد Validate استفاده شده، همواره مقدار false را بر میگرداند:
_identityVerifier.Initialize(); var isValidIdentity = _identityVerifier.Validate( application.Applicant.Name, application.Applicant.Age, application.Applicant.Address);
در ادامه شیء Mock از نوع IIdentityVerifier را طوری تنظیم خواهیم کرد که بر اساس یک applicant مشخص، خروجی true را بازگشت دهد:
namespace Loans.Tests { [TestClass] public class LoanApplicationProcessorShould { [TestMethod] public void Accept() { var product = new LoanProduct {Id = 99, ProductName = "Loan", InterestRate = 5.25m}; var amount = new LoanAmount {CurrencyCode = "Rial", Principal = 2_000_000_0}; var applicant = new Applicant {Id = 1, Name = "User 1", Age = 25, Address = "This place", Salary = 1_500_000_0}; var application = new LoanApplication {Id = 42, Product = product, Amount = amount, Applicant = applicant}; var mockIdentityVerifier = new Mock<IIdentityVerifier>(); mockIdentityVerifier.Setup(x => x.Validate(applicant.Name, applicant.Age, applicant.Address)) .Returns(true); var mockCreditScorer = new Mock<ICreditScorer>(); var processor = new LoanApplicationProcessor(mockIdentityVerifier.Object, mockCreditScorer.Object); processor.Process(application); Assert.IsTrue(application.IsAccepted); } } }
به این ترتیب زمانیکه در متد Process کلاس LoanApplicationProcessor کار به بررسی هویت کاربر میرسد، اگر متد Validate آن با اطلاعات applicant مشخصی که تنظیم کردیم، یکی بود، متغیر isValidIdentity که حاصل بررسی identityVerifier.Validate_ است، به true مقدار دهی خواهد شد. برای بررسی آن یک break-point را در این نقطه قرار داده و آزمون واحد را در حالت دیباگ اجرا کنید.
البته هرچند اگر اکنون نیز این آزمایش واحد را مجددا بررسی کنیم، باز هم با شکست مواجه خواهد شد؛ چون مرحلهی بعدی بررسی، کار با سرویس ICreditScorer است که هنوز تنظیم نشدهاست:
_creditScorer.CalculateScore(application.Applicant.Name, application.Applicant.Address); if (_creditScorer.Score < MinimumCreditScore) { return application.IsAccepted; }
تطابق با آرگومانهای متدها در متدهای Mock شده
با تنظیمی که انجام دادیم، اگر متد Validate به مشخصات شیء applicant مشخص ما برسد، خروجی true را بازگشت میدهد. برای مثال اگر در این بین تنها نام شخص تغییر کند، خروجی بازگشت داده شده همان false خواهد بود. اما اگر این نام برای ما اهمیتی نداشت و قصد داشتیم با تمام نامهای متفاوتی که دریافت میکند، بازهم خروجی true را بازگشت دهد، میتوان از قابلیت argument matching کتابخانهی Moq و کلاس It آن استفاده کرد:
var mockIdentityVerifier = new Mock<IIdentityVerifier>(); mockIdentityVerifier.Setup(x => x.Validate( //applicant.Name, It.IsAny<string>(), applicant.Age, applicant.Address)) .Returns(true);
بدیهی است در این حالت باید سایر پارامترها دقیقا با مقادیر مشخص شده تطابق داشته باشند و اگر این موارد نیز اهمیتی نداشتند، میتوان به صورت زیر عمل کرد:
var mockIdentityVerifier = new Mock<IIdentityVerifier>(); mockIdentityVerifier.Setup(x => x.Validate( //applicant.Name, It.IsAny<string>(), //applicant.Age, It.IsAny<int>(), //applicant.Address It.IsAny<string>() )) .Returns(true);
البته این نوع تنظیمات بیشتر برای حالات غیرمشخص مانند استفادهاز Guidها به عنوان پارامترها و مقادیر، میتواند مفید باشد.
تقلید متدهایی که پارامترهایی از نوع out دارند
اگر به اینترفیس IIdentityVerifier که در قسمت قبل معرفی شد دقت کنیم، یکی از متدهای آن دارای خروجی از نوع out است:
using Loans.Models; namespace Loans.Services.Contracts { public interface IIdentityVerifier { void Validate(string applicantName, int applicantAge, string applicantAddress, out bool isValid); // ... } }
//var isValidIdentity = _identityVerifier.Validate( // application.Applicant.Name, application.Applicant.Age, application.Applicant.Address); _identityVerifier.Validate( application.Applicant.Name, application.Applicant.Age, application.Applicant.Address, out var isValidIdentity);
var isValidOutValue = true; mockIdentityVerifier.Setup(x => x.Validate(applicant.Name, applicant.Age, applicant.Address, out isValidOutValue));
اکنون اگر مجددا آزمون واحد متد Accept را اجرا کنیم، با موفقیت به پایان میرسد.
تقلید متدهایی که پارامترهایی از نوع ref دارند
اگر به اینترفیس IIdentityVerifier که در قسمت قبل معرفی شد دقت کنیم، یکی از متدهای آن دارای خروجی از نوع ref است:
using Loans.Models; namespace Loans.Services.Contracts { public interface IIdentityVerifier { void Validate(string applicantName, int applicantAge, string applicantAddress, ref IdentityVerificationStatus status); // ... } }
namespace Loans.Models { public class IdentityVerificationStatus { public bool Passed { get; set; } } }
IdentityVerificationStatus status = null; _identityVerifier.Validate( application.Applicant.Name, application.Applicant.Age, application.Applicant.Address, ref status); if (!status.Passed) { return application.IsAccepted; }
ابتدا در سطح کلاس آزمایش واحد یک delegate را تعریف میکنیم:
delegate void ValidateCallback(string applicantName, int applicantAge, string applicantAddress, ref IdentityVerificationStatus status);
اکنون روش استفادهی از آن برای برپایی تنظیمات mocking متد Validate از نوع ref دار به صورت زیر است:
mockIdentityVerifier .Setup(x => x.Validate(applicant.Name, applicant.Age, applicant.Address, ref It.Ref<IdentityVerificationStatus>.IsAny)) .Callback(new ValidateCallback( (string applicantName, int applicantAge, string applicantAddress, ref IdentityVerificationStatus status) => status = new IdentityVerificationStatus {Passed = true}));
سپس متد جدید Callback را مشاهده میکنید. توسط آن میتوان یک قطعه کد سفارشی را زمانیکه متد Mock شدهی Validate ما اجرا میشود، اجرا کرد. در اینجا delegate سفارشی ما اجرا شده و مقدار status را بر میگرداند؛ اما در ادامه این مقدار را به یک new IdentityVerificationStatus سفارشی تنظیم میکنیم که در آن مقدار خاصیت Passed، مساوی true است.
اکنون اگر مجددا آزمون واحد متد Accept را اجرا کنیم، با موفقیت به پایان میرسد.
تنظیم متدهای Mock شده جهت بازگشت null
فرض کنید اینترفیسی به صورت زیر تعریف شدهاست:
namespace Loans.Services.Contracts { public interface INullExample { string SomeMethod(); } }
namespace Loans.Tests { [TestClass] public class LoanApplicationProcessorShould { [TestMethod] public void NullReturnExample() { var mock = new Mock<INullExample>(); mock.Setup(x => x.SomeMethod()); //.Returns<string>(null); string mockReturnValue = mock.Object.SomeMethod(); Assert.IsNull(mockReturnValue); } } }
الف) میتوان همانند سابق متد Returns را ذکر کرد که نال بر میگرداند؛ اما با این تفاوت که حتما باید نوع آرگومان جنریک آنرا نیز بر اساس خروجی متد، مشخص کرد.
ب) کتابخانهی Moq، مقدار خروجی پیشفرض تمام متدهایی را که یک نوع ارجاعی را باز میگردانند، نال درنظر میگیرد و عملا نیازی به ذکر متد Returns در اینجا نیست.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: MoqSeries-02.zip
نظرات مطالب
پردازشهای Async در Entity framework 6
با تشکر ازشما.
میخواستم بدونم متدهای async چطور در یک repository استفاده کنم
بطور مثال:
public class ProductRepository<T> where T : class { protected DbContext _context; public ProductRepository(DataContext context) { _context = context; } // GetAll
همانطوری که میدونید نسخه
MVC 4 RC در دسترس قرار گرفته و خالی از لطف نیست که یک بررسی درباره امکانات جدیدش انجام بشه.ابتدا سعی میکنم یک لیست کلی از امکانان این تکنولوژی داشته باشیم و بعد نگاهی هم به Razor و تغییراتش خواهیم داشت.
ASP.NET Web API
Refreshed and modernized default project templates
New mobile project template
Many new features to support mobile apps
Recipes to customize code generation
Enhanced support for asynchronous methods
لیست فوق شامل برترین ویژگیهای این نسخه است که در پستهای آینده هر کدام از اینها بررسی خواهند شد.
تغییرات Razor
Razor از نسخه MVC4 Beta شاهد تغییرات و بهبود هایی بود که این تغییرات بنیادی و رادیکالی نبودند و فقط درجهت بهبود حس کاربری آن صورت گرفت. این حس از آن جهت است که شما نیاز به نوشتن کد کمتری دارید.
استفاده نکردن از Url.Content@
در نسخه قبلی از امکان ذکر شده برای مشخص کرده مسیرهای CSS و فایلهای .JS هم استفاده میشد حالا بجای استفاده از آن میشود:
در نسخههای قبلی:
در نسخه 4:
<script src="@Url.Content("~/Scripts/Site.js")"></script>
<script src="~/Scripts/Site.js"></script>
زمانی که Razor حرف را ~/ تشخیص میدهد خروجی یکسانی با حالت قبلی برای ما درست میکند.
شرط ها(Conditions)
در نسخه قبلی برای استفاده از attribute ها که ممکن بود Null باشند مجبور به چک کردن آنها بودیم:
<div @{if (myClass != null) { <text>class="@myClass"</text> } }>Content</div>
اما حالا با خیال راحت میتوان نوشت:
<div class="@myClass">Content</div>
که اگر attribute ما null باشد به صورت اتوماتیک تشخیص داده میشود و کد زیر رندر میشود
<div>Content</div>
در ضمناً کد بالا فقط مربوط به چک کردن Nullable نیست و از آن میتوان در Booleanها هم استفاده کرد.
<input checked="@ViewBag.Checked" type="checkbox"/>
که اگر مقدار True نباشد:
<input type="checkbox"/>
بطور خلاصه میشه گفت MVC4 تغییراتش نسبت به نسخه قبلی تو خیلی از زمینهها مربوط میشه بهبود ابزارهای موجود در کل کار با این ایزار بسیار برای من لذت بخشه.
ادامه دارد...