- خیر. با هم هست.
- بله. مراجعه کنید به مطالب و مستندات پروژهی PDF Report برای اطلاعات بیشتر.
- بله. مراجعه کنید به مطالب و مستندات پروژهی PDF Report برای اطلاعات بیشتر.
بازخوردهای پروژهها
در صورت امکان فایل مستندات کدها قرار داده شود
فایل مستندات با استفاده از نرم افزار Sandcastle قرار داده شود
فایلهای پروژهها
ShopDocumentation 1.0.chm
مستندات کدهای نوشته شده در لایه دیتا و لایه تجاری
کتابخانهی iTextSharp، یا همان برگردان iText جاوا، انصافا اینقدر حرف برای گفتن دارد که یک کتاب 600 صفحهای برای آن چاپ شده است، اما ... در حین استفاده از آن مشکل زیر (که به شکل وسیعی در قسمتهای مختلف آن وجود دارد) قابل هضم نیست:
یکی از مواردی را که در حین طراحی یک API خوب باید در نظر گرفت، کمک به استفاده کننده در عدم بکارگیری Magic numbers است. حالا این Magic numbers یعنی چی؟
برای مثال قطعه کد زیر را در نظر بگیرید:
new Font(baseFont, 10, 0, BaseColor.BLACK)
نگارش بهبود یافته کد فوق به شرح زیر است:
new Font(baseFont, 10, Font.NORMAL, BaseColor.BLACK)
- استفاده کننده محدودیتی در بکارگیری مقادیر ندارد، چون آرگومانها از نوع int معرفی شدهاند. ممکن است اشتباهی رخ دهد.
- باز هم نیاز است به مستندات کتابخانه مراجعه کرد، زیرا نوع int هیچ نوع منوی intellisense خاصی را ظاهر نمیکند.
public enum PdfFontStyle
{
Normal = 0,
Bold = 1,
Italic = 2,
Underline = 4,
Strikethru = 8,
BoldItalic = Bold | Italic
}
یکی از نیازهای تهیه یک گزارش خوب، تکرار سرستونها در صفحات مختلف است. شاید در ابتدا این ایده مطرح شود که مثلا میخواهیم 25 ردیف را در هر صفحه نمایش دهیم. بر همین اساس میتوان هر 25 ردیف یکبار، یک سطر footer و در ادامه در صفحه بعد یک سطر header را اضافه کرد و همینطور الی آخر. مهمترین ایراد این روش آن است که الزامی ندارد که واقعا 25 ردیف در یک صفحه جا شوند. عموما بر اساس اندازهی محتوای نمایش داده شده، ممکن است یک صفحه 20 ردیف شود، صفحهای دیگر 10 ردیف. این مورد تمام محاسبات را به هم خواهد ریخت. به همین جهت دو خاصیت مهم به نامهای HeaderRows و FooterRows در شیء PdfPTable قابل تنظیم است. این دو خاصیت نیاز به اندکی توضیح دارند که در ادامه ذکر خواهد شد:
using System.Diagnostics;
using System.IO;
using iTextSharp.text;
using iTextSharp.text.pdf;
namespace HeadersAndFooters
{
class Program
{
static void Main(string[] args)
{
using (var pdfDoc = new Document(PageSize.A4))
{
var pdfWriter = PdfWriter.GetInstance(pdfDoc, new FileStream("Test.pdf", FileMode.Create));
pdfDoc.Open();
var table1 = new PdfPTable(1);
table1.HeaderRows = 2;
table1.FooterRows = 1;
//header row
table1.AddCell(new Phrase("header"));
//footer row
table1.AddCell(new Phrase("footer"));
//adding some rows
for (int i = 0; i < 70; i++)
{
table1.AddCell(new Phrase("Row " + i));
}
pdfDoc.Add(table1);
}
//open the final file with adobe reader for instance.
Process.Start("Test.pdf");
}
}
}
HeaderRows = 2 به این معنا است که 2 سطری را که بلافاصله در ادامه اضافه میکنید، در محاسبات نمایش خودکار header یا footer قرار میگیرند. FooterRows = 1 به این معنا است که از این تعداد، آخرین سطر، معنای footer را میدهد. بنابراین اولین table1.AddCell ، همان header خودکار نمایش داده شده در بالای تمام صفحات خواهد بود و table1.AddCell بعدی جهت نمایش footer خودکار بکار میرود. این دو سطر کاربرد دیگری ندارند.
مثالی دیگر جهت مشخص شدن این مفاهیم:
table1.HeaderRows = 3;
table1.FooterRows = 1;
از این طراحی لذت میبرید؟!
نظرات مطالب
ASP.NET MVC #5
من نگفتم MS-PL متن باز نیست. این مجوز پذیرفته شده OSI است (^).
متن باز بودن هم به معنای آزادی مطلق نیست. مثلا مجوز GPL به شما میگه که من سورس کارت رو هم میخوام اگر از کتابخانه من استفاده کردی یا اینکه باید با من به نحوی کنار بیای و هماهنگ کنی.
یا مجوز MIT میگه من نمیخوام و مهم نیست؛ یک تشکر برای من کافی است.
مجوز MS-PL بیشتر معنای (Shared source) رو از طرف مایکروسافت داره. به عبارتی مجاز هستید در فرم بایناری در هر نوع پروژهای از آن استفاده کنید. اما در حالت سورس، فقط جهت مرور و یا یافتن مشکلات امنیتی یا بررسیهای امنیتی در اختیار عموم قرار گرفته است (مثلا بعضی از دولتها به این مساله حساس هستند و سورس رو جهت بررسی امنیتی نیاز دارند). اما با این حال:
- مجاز هستید سورس رو تغییر بدید و حتی بفروشید اما باز هم تحت مجوز MS-PL
- اگر کاری جدیدی بر مبنای این سورس (نه بایناری آن که عنوان شد) تهیه شود، هم باید سورس را ارائه دهید و هم باز هم کل کار باید تحت مجوز MS-PL باشد.
رفتار مایکروسافت با این مجوز خاص خودش، فقط خواندنی است. یعنی پچی رو قبول نمیکنه.
به همین جهت این رفتار رو اخیرا اصلاح کردن و به مجوز آپاچی نقل مکان کردند و از حالت shared code فقط خواندنی بیشتر جهت بررسیهای امنیتی و مرور کد، به یک حالت پویاتر تبدیل شده.
متن باز بودن هم به معنای آزادی مطلق نیست. مثلا مجوز GPL به شما میگه که من سورس کارت رو هم میخوام اگر از کتابخانه من استفاده کردی یا اینکه باید با من به نحوی کنار بیای و هماهنگ کنی.
یا مجوز MIT میگه من نمیخوام و مهم نیست؛ یک تشکر برای من کافی است.
مجوز MS-PL بیشتر معنای (Shared source) رو از طرف مایکروسافت داره. به عبارتی مجاز هستید در فرم بایناری در هر نوع پروژهای از آن استفاده کنید. اما در حالت سورس، فقط جهت مرور و یا یافتن مشکلات امنیتی یا بررسیهای امنیتی در اختیار عموم قرار گرفته است (مثلا بعضی از دولتها به این مساله حساس هستند و سورس رو جهت بررسی امنیتی نیاز دارند). اما با این حال:
- مجاز هستید سورس رو تغییر بدید و حتی بفروشید اما باز هم تحت مجوز MS-PL
- اگر کاری جدیدی بر مبنای این سورس (نه بایناری آن که عنوان شد) تهیه شود، هم باید سورس را ارائه دهید و هم باز هم کل کار باید تحت مجوز MS-PL باشد.
رفتار مایکروسافت با این مجوز خاص خودش، فقط خواندنی است. یعنی پچی رو قبول نمیکنه.
به همین جهت این رفتار رو اخیرا اصلاح کردن و به مجوز آپاچی نقل مکان کردند و از حالت shared code فقط خواندنی بیشتر جهت بررسیهای امنیتی و مرور کد، به یک حالت پویاتر تبدیل شده.
یک: ASP.NET Core مستقل از Platform است
آیندهی محتوم نرمافزار، توسعه به شیوههای مستقل از Platform است. شاید این دلیل به تنهایی برای مهاجرت به ASP.NET Core کافی باشد. امروزه نرمافزارهایی که مبتنی بر یک Platform خاص نیستند، نسبت به سایر نرمافزارها مزیت رقابتیتری دارند. نرمافزارهای Cross Platform یا مستقل از Platform، بر روی هر سیستم عاملی اجرا میشوند. برای اجرای آنها در کامپیوترهای شخصی یا Server کافیست معماری پردازندهی مرکزی x86 باشد و سیستم عامل نیز یکی از انواع ویندوز، لینوکس یا مک.
دلیل مستقل بودن ASP.NET Core از Platform، مبتنی بودن آن بر NET Core. است. این نسخه از داتنت را میتوان برای سیستمعاملهای مختلف از http://dot.net دانلود و نصب کرد.
برای اجرای نرمافزارهایی که مبتنی بر NET Core. هستند نیاز به بازنویسی کدها یا استفاده از زبانهای برنامهنویسی جداگانهای نیست. این خاصیت همچنین برای libraryهای استانداردی که از این نسخه از داتنت استفاده میکنند نیز صادق است.
دو: Open Source است
یکی از انتقادهایی که سالها به مایکروسافت میشد، ناشناخته بودن سورس نرمافزارهای این شرکت و انحصار طلبیهایش بود. اما در سالهای اخیر مایکروسافت نشان دادهاست که این جنبه از کاراکترش را به تدریج اصلاح کردهاست. به طوری که اسکات هانسلمن، یکی از کارمندان این شرکت و وبلاگنویس مشهور در این مورد گفته است:
دلیل آمدن من به مایکروسافت این بود که میخواستیم هر چقدر میتوانیم کارها را Open Source کنیم و یک جامعهی کاربری برای داتنت و اوپن سورس بسازیم و حالا به NET Core 1.0. رسیدهایم.
زمانی شایعهی لو رفتن بخشی از سورس کد ویندوز ۹۵، در صدر اخبار تکنولوژی بود و این یک شکست برای مایکروسافت محسوب میشد. اما امروزه ASP.NET Core با لایسنس MIT عرضه شده است که یکی از آزادترین مجوزهای اوپن سورس است. نرمافزارهایی که با این مجوز عرضه میشوند، آزادی تغییر کد، ادغام با مجوزهای دیگر، عرضه به عنوان محصول دیگر، استفاده تجاری و ... را به همهی توسعهدهندگان میدهد.
سه: جدا بودن از Web Server
این نسخهی از APS.NET، کاملاً از وبسرور که نرمافزارها را هاست میکند، جدا (decouple) شده است. اگرچه همچنان استفاده از IIS بر روی ویندوز منطقی به نظر میرسد اما مایکروسافت یک پروژهی اوپن سورس دیگری را به نام Kestrel نیز منتشر کرده است.
وبسرور Kestrel مبتنی بر پروژه libuv است و libuv در اصل برای هاست کردن Node.js تولید شده بود و تأکید آن بر روی انجام عملیات I/O به صورت asynchronous است.
نکته جالب این است که یک برنامهی مبتنی بر ASP.NET Core، در واقع یک Console Application است که در متد Main آن وبسرور فراخوانی میشود:
using System; using Microsoft.AspNetCore.Hosting; namespace aspnetcoreapp { public class Program { public static void Main(string[] args) { var host = new WebHostBuilder() .UseKestrel() .UseStartup<Startup>() .Build(); host.Run(); } } }
چهار: تزریق وابستگی (Dependency Injection) تو کار
تزریق وابستگیها برای ایجاد وابستگی سست (loosely coupling) بین اشیاء مرتبط و وابسته به یکدیگر است. به جای نمونهسازی مستقیم اشیاء مرتبط، یا استفاده از ارجاعهای ایستا به آن اشیاء، زمانی که یک کلاس به آنها احتیاج داشته باشد، با روشهای خاصی از طریق DI به اشیاء مورد نیاز دسترسی پیدا میکند. در این استراتژی، ماژولهای سطح بالا نباید به ماژولهای سطح پایین وابسته باشند، بلکه هر دو باید به abstraction (معمولا Interface ها) وابسته باشند.
وقتی یک سیستم برای استفادهی از DI طراحی شدهاست و کلاسهای زیادی دارد که وابستگیهایش را از طریق constructor یا propertyها درخواست میکند، بهتر است یک کلاس مخصوص ایجاد آن کلاسها و وابستگیهایشان داشته باشد. به این کلاسها container، یا Inversion of Control (IoC) container یا Dependency Injection (DI) container گفته میشود.
با این روش، بدون نیاز به hard code کردن instance سازی از کلاسها، میتوان گرافهای پیچیده وابستگی را در اختیار یک کلاس قرار داد.
طراحی ASP.NET Core از پایه طوری است که حداکثر استفاده را از Dependency Injection میکند. یک container ساده توکار با نام IServiceProvider وجود دارد که به صورت پیشفرض constructor injection را پشتیبانی میکند.
در ASP.NET Core با مفهومی به نام service سر و کار خواهید داشت که در واقع به type هایی گفته میشود که از طریق DI در اختیار شما قرار میگیرند. سرویسها در متد ConfigureServices کلاس Startup برنامه شما تعریف میشوند. این serviceها میتوانند Entity Framework Core یا ASP.NET Core MVC باشند یا سرویسهایی که توسط شما تعریف شدهاند. مثال:
// This method gets called by the runtime. Use this method to add services to the container. public void ConfigureServices (IServiceCollection services) { // Add framework services. services.AddDbContext<ApplicationDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))); services.AddIdentity<ApplicationUser, IdentityRole>() .AddEntityFrameworkStores<ApplicationDbContext>() .AddDefaultTokenProviders(); services.AddMvc(); // Add application services. services.AddTransient<IEmailSender, AuthMessageSender>(); services.AddTransient<ISmsSender, AuthMessageSender>(); }
پنج: یکپارچگی با frameworkهای مدرن سمت کلاینت
فرآیند build در برنامههای تحت وب مدرن معمولاً این وظایف را انجام میدهد:
- bundle و minify کردن فایلهای جاوا اسکریپت و همینطور CSS
- اجرای ابزارهایی برای bundle و minify کردن قبل از هر build
- کامپایل کردن فایلهای LESS و SASS در CSS
- کامپیال کردن فایلهای CoffeeScript و TypeScript در JavaScript
برای اجرای چنین فرآیندهایی از ابزاری به نام task runner استفاده میشود که Visual Studio از دو ابزار task runner مبتنی برا جاوا اسکریپت به نامهای Gulp و Grunt بهره میبرد. از این ابزارها با استفاده از ASP.NET Core Web Application template میتوان در ASP.NET Core استفاده کرد.
همچنین امکان استفاده از Bower که یک package manager (مانند NuGet) برای وب است، وجود دارد. معمولاً از Bower برای نصب فایلهای CSS ، فونتها، frameworkهای سمت کلاینت و کتابخانههای جاوا اسکریپت استفاده میشود. اگرچه بسیاری از packageها در NuGet هم وجود دارند، اما تمرکز بیشتر NuGet بر روی کتابخانههای داتنتی است.
نصب و استفادهی سایر libraryهای سمت کلاینت مانند Bootstrap ، Knockout.js ، Angular JS و زبان TypeScript نیز در Visual Studio و هماهنگی آن با ASP.NET Core نیز بسیار ساده است.
پس همین حالا دست به کار شوید و با نصب -حداقل - Microsoft Visual Studio 2015 Update 3 بر روی ویندوز یا Visual Studio Code بر روی هر سیستم عاملی از برنامهنویسی با ASP.NET Core لذت ببرید!
منابع :