EF Code First #11
- بله. اسامی مهم نیست. یکی عنوان میکند BLL یکی Infrastructure یکی Service یکی...
- خروجی لایه سرویس فقط باید از نوع اشیاء معمولی، لیست یا IEnumerable باشد. اگر از IQueryable به عنوان خروجی متد استفاده کردید، به یک Abstraction دارای «نشتی» خواهید رسید. چون به سادگی خارج از منطقی که مدنظر بوده کاملا قابل تغییر است.
- God Class کلاسی است که اطلاعات زیادی را در اختیار سایرین قرار میدهد، نه کلاسی که جهت برآورده سازی منطق تجاری برنامه، از اطلاعات زیادی استفاده میکند. کلاسی که 1000 تا متد را در اختیار سایر کلاسها قرار میدهد God class نام دارد. نه متدی که برای عملکرد صحیح خود نیاز به اطلاعات زیادی است.
معرفی کتابخانهی DNTCaptcha.Core
- ابتدا ApiSettingsController.cs اضافه شد تا تنظیمات ApiSettings را به سمت کلاینت بازگشت دهد.
- سپس api-config.service.ts جهت خواندن این تنظیمات تعریف و به ماژول Core اضافه شد تا در ابتدای اجرای برنامهی کلاینت، پیش از هر کد دیگری اجرا شود.
- تغییرات مورد نیاز آنرا در اینجا میتوانید مشاهده کنید و یا آخرین نگارش پروژه را دریافت کنید.
برای آزمایش آن، اگر برنامهی سرور (در ابتدا؛ جهت مهیا شدن قسمت دریافت تنظیمات سمت سرور ) و سپس کلاینت را اجرا کنید، تنظیمات دریافتی را در کنسول توسعه دهندگان مرورگر، مشاهده خواهید کرد:
ردیابی تغییرات در Entity Framework، بخش اول
برای نگهداری لیست کارهای روزمره بیشتر از ابزارهای دیجیتال(Excel, Evernote, ..) استفاده میکنید و یا فیزیکی(دفترچه، تخته و...)؟
کلا از مصرف گرایی خوشم نمیاد و 80 درصد کارهای یک پروژه را روی سیستمهای دیجیتالی انجام میدهم و عمدتا از سیستمهای مدیریت پروژه انلاین ( Trello) استفاده میکنم.
حتی زمانی که مجبور به استفاده از کاغذ یا دفترچه باشم فقط از چک پرینتهای موجود در دفتر و برای نوشتن از مداد استفاده میکنم.
استفاده از سیستمهای دیجیتال هم به صرفه تره هم امن تره! اما به گفته دوستمان، لذت استفاده از دفترچه و برگههای یادداشت فیزیکی به یادماندنیتر است!
smc.version = "0"
defaults write com.apple.finder AppleShowAllFiles YES
defaults write com.apple.CoreSimulator.IndigoFramebufferServices FramebufferEmulationHint 1
امکان تست بر روی بر روی آخرین نسخه iOS یعنی 12 بر روی iPhone 5s تا iPhone XS Max وجود دارد. علاوه بر این میتوانید iOS 12 را روی iPad نسل پنج و شش و iPad Air 1 و 2 و iPad Pro تست کنید. اگر قصد تست روی نسخههای قدیمیتر iOS، چون iOS 11 یا سایر دستگاهها را دارید، باید ابتدا در XCode، از منوی Window به Devices and simulators بروید و در تب Simulators روی + کلیک کنید. در قسمت OS version میتوانید نسخههای قدیمیتر را دانلود کنید یا برای Apple TV و Apple Watch نیز Simulator بسازید.
برنامه را روی iPhone 6 یا یک گوشی سبک و ساده دیگر گذاشته و برنامه را اجرا کنید و تست بگیرید. دقت کنید که Simulator روی ویندوز اجرا میشود و نیازی به سوئیچ مداوم بین ویندوز و Mac نیست. ولی اگر Simulator روی ویندوز از لحاظ UI ای عملکرد مناسبی را نداشت، در ویژوال استودیو به منوی Tools رفته و از Options > Xamarin > iOS settings تیک Remote simulator to Windows را بردارید که باعث میشود Simulator در Mac اجرا شود. در هر بار عوض کردن Simulator از گوشی ای به گوشی دیگر، پروژه را Clean - Rebuild کنید.
در سریهای بعد که ویژوال استودیو را باز میکنید، از منوی Tools > iOS گزینه Pair Mac را بزنید و به Mac خود متصل شوید.
برای اینکه بتوانید روی گوشی تست بگیرید، در همین عکس بالا، به جای iPhoneSimulator، گزینه iPhone را انتخاب کنید. بهتر است گوشی به آخرین نسخه iOS آپدیت شده باشد. همچنین iTunes for windows را نصب کنید تا ابتدا ویندوز، گوشی شما را که با کابل به کامپیوتر وصل کردهاید بشناسد. سپس در VM Ware درخواست کنید که گوشی به جای ویندوز، به Virtual Machine مک شما وصل شود. در قسمت پایین - سمت راست VM Ware برای هر سخت افزار متصل به کامپیوتر، یک گزینه هست که آنهایی که پر رنگ هستند، سخت افزارهای متصل به Virtual Mac بوده و کمرنگها را Mac نمیبیند. روی سخت افزار گوشی خود کلیک کنید و Connect را بزنید. حال باید بتوانید در iTunes موجود در Mac، اطلاعات مربوط به گوشی خود را مشاهده کنید.
به ویژوال استودیو برگشته و در قسمت Properties پروژه XamApp.iOS، به تب iOS Bundle signing رفته و ضمن انتخاب Automatic provisioning، در قسمت Team، تیم خود را انتخاب کنید. این Team را در زمان ساخت Apple Developer account ایجاد کردهاید و همانطور که قبلا در این آموزش گفته شد، اگر در ویژوال استودیو با آن لاگین کرده باشید، میتوانید آن را ببینید. در صورتی که Apple Developer account ندارید، بر اساس این آموزش پیش بروید.
زمانیکه برنامه را روی گوشی اجرا میکنید، ممکن است در Mac دیالوگ گرفتن نام کاربری و رمز عبور کاربر Mac باز شود، پس نیم نگاهی به آن داشته باشید. پس از اولین اجرای موفق روی گوشی میتوانید در XCode به منوی Window رفته و سپس Devices & simulators را باز کنید و گوشی خود را در قسمت Devices انتخاب کرده و تیک Connect via network را بزنید تا از این به بعد، بدون کابل نیز بتوانید روی گوشی خود تست کنید. البته گوشی، ویندوز و مک، باید در یک شبکه باشند.
نحوه پابلیش پروژه را در مقاله مربوط به App Center خواهیم نوشت. اما به صورت خلاصه حجم فایل ipa حدود 10 مگ است که شامل تمامی مواردی است که در قسمت Android توضیح دادیم و پروژه نهایی شما حجمی در همین حدود خواهد داشت و با اضافه کردن چندین فرم حجم اضافه نمیشود. همانطور که در قسمت توضیحات پیشرفته پروژه اندروید توضیح دادیم، اینجا نیز از AOT و LLVM برای دستیابی به بالاترین سرعت ممکن کدهای Native استفاده شده و کدهای اضافه از پروژه Link (حذف) میشوند. برای اینکار، در ویژوال استودیو iPhone - Release را انتخاب کنید و پروژه را بیلد کنید. فایل ipa درون Mac در فولدر
Library ▸ Caches ▸ Xamarin ▸ mtbs ▸ builds ▸ XamApp.iOS ▸ e9979ba2348d1c5a87390643d62c4a1b ▸ bin ▸ iPhone ▸ Release ▸ XamApp.iOS.ipa
ساخته میشود که Library فولدری در User شما بوده و مقدار Guid مربوطه، Random است. همچنین XamApp.iOS نام پروژه است.
حالتهای متصور برای عکس بالا عبارتند از [Debug - iPhoneSimulator] و [Debug - iPhone] و [Release - iPhone] که دو تای اول برای تست روی Simulator و Device بوده و حالت سوم برای Release کردن فایل ipa. طبیعی است که تنظیم [Release - Simulator] معنی نمیدهد.
با توجه به اینکه محیط توسعه برنامه را آماده کردهایم، از قسمت بعد، به آموزش کدنویسی خواهیم پرداخت.
// webpack.config.js file module.exports = { entry:'./main.js' ,output:{ filename:'bundle.js' } }
//for when webpack is installed globally webpack --watch //for when webpack is installed locally in project npm run webpack -- --watch
//webpack.config.js file module.exports = { entry:'./main.js' ,output:{ filename:'bundle.js' } ,watch :true }
// to install globally : npm install -g webpack-dev-server //to install locally in project : npm install -D webpack-dev-server
//package.json file { "name": "dntwebpack", "version": "1.0.0", "description": "", "main": "main.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "webpack": "webpack", "webpackserver": "webpack-dev-server" }, "author": "mehdi", "license": "ISC", "devDependencies": { "webpack": "^1.13.1", "webpack-dev-server": "^1.14.1" } }
npm run webpackserver
// user.js file function userLog() { console.log("ahooy from user module file"); } module.exports={ userLog:userLog }
//main.js file var user = require("./user"); user.userLog(); console.log(`i'm bundled by webpack`);
// shared.js file console.log('log message from shared module !');
//webpack.config.js file module.exports = { entry:['./shared.js','./main.js'] ,output:{ filename:'bundle.js' } ,watch :true }
npm install -D ts-loader
// main.ts file let user = require("./user"); user.userLog(); let mainlogger = () => { console.log(`i'm bundled by webpack in an arrow function`); } mainlogger();
//webpack.config.js module.exports = { entry:['./shared.js','./main.js'] ,output:{ filename:'bundle.js' } ,watch :true ,module:{ loaders:[ { test:/\.ts$/ ,exclude:/node_modules/ ,loader:'ts-loader' } ] } }
ICriteria API در NHibernate پیاده سازی الگوی Query Object است. مشکلی هم که این روش دارد استفاده از رشتهها جهت ایجاد کوئریهای متفاوت است؛ به عبارتی Type safe نیست. ایرادی هم به آن وارد نیست چون پیاده سازی اولیه آن از جاوا صورت گرفته و مباحث Lambda Expressions و Extension Methods هنوز در آن زبان به صورت رسمی ارائه نشده است (در JDK 7 تحت عنوان Closures قرار است اضافه شود). NHibernate 3.0 از ویژگیهای جدید زبانهای دات نتی جهت ارائهی محصور کنندهای Type safe حول ICriteria API استاندارد به نام QueryOver API سود جسته است. این پیاده سازی بسیار شبیه به عبارات LINQ است اما نباید با آن اشتباه گرفته شود زیرا LINQ to NHibernate یک ویژگی دیگر جدید، یکپارچه و استاندارد NHibernate 3.0 به شمار میرود.
برای نمونه در یک ICriteria query متداول، فراخوانیهای ذیل متداول است:
.Add(Expression.Eq("Name", "Smith"))
.Where<Person>(p => p.Name == "Smith")
مزیتهای این روش (strongly-typed fluent API) به شرح زیر است:
- خبری از رشتهها جهت استفاده از یک خاصیت وجود ندارد. برای مثال در اینجا خاصیت Name کلاس Person تحت کنترل کامپایلر قرار میگیرد و اگر در کلاس Person تغییراتی حاصل شود، برای مثال Name به LName تغییر کند، برنامه دیگر کامپایل نخواهد شد. اما در حالت ICriteria API یا باید به نتایج حاصل از Unit testing مراجعه کرد یا باید به نتایج بازخورد کاربران برنامه مانند: "باز برنامه رو تغییر دادی، یکجای دیگر از کار افتاد!" دقت نمود!
- اگر در حین ویرایش کلاس Person از ابزارهای Refactoring استفاده شود، تغییرات حاصل به صورت خودکار به تمام برنامه نیز اعمال خواهد شد. بدیهی است این اعمال تغییرات تنها در صورتی میسر است که خاصیت مورد نظر به صورت رشته معرفی نگردیده و ارجاعات به اشیاء تعریف شده به سادگی قابل parse باشند.
- در این حالت امکان بررسی نوع خواص تغییر کرده نیز توسط کامپایلر به سادگی میسر است و اگر ارجاعات تعریف شده به نحو صحیحی از این نوع جدید استفاده نکنند باز هم برنامه تا رفع این مشکلات کامپایل نخواهد شد که این هم مزیت مهمی در نگهداری سادهتر یک برنامه است.
- با بکارگیری Extension methods و پیاده سازی Fluent API جدید، مدت زمان یادگیری این روش نیز به شدت کاهش یافته، زیرا Intellisense موجود در VS.NET بهترین راهنمای استفاده از امکانات فراهم شده است. برای مثال جهت استفاده از ویژگی جدید QueryOver به سادگی میتوان پس از ساختن یک session جدید به صورت زیر عمل نمود:
IList<Cat> cats = session.QueryOver<Cat>().Where(c => c.Name == "Max").List();
جهت مشاهدهی معرفی کامل آن میتوان به مستندات NHibernate 3.0 مراجعه کرد.