تور آشنایی با پلتفرم خودکار قسمت یازدهم

متن صدای ویدیو :

با عرض سلام و ادب کیایی هستم، مدیر وبسایت dotnetexpert.ir و نویسنده ی platform خودکار، با یک سری دیگر از ویدئوهای تور آشنایی با platform خودکار در خدمتتان هستم.

خوب در این قسمت می خواهیم بیشتر درباره ی کدنویسی سمت server صحبت کنیم. من از منوی توسعه، مدیریت کدها، کدهای تحت سیستم عامل کدهای تحت dotnet و مدیریت اسمبلی ها ، اگر یادتان باشد ما در ویدئوهای قبلی گفتیم که شما زمانی که می خواهید برنامه تان را بنویسید باید dll های برنامه تان را که لایه های برنامه های شما هستند حالا به طور معمول پنج لایه تان را مانند لایه ی ui لایه ی business لایه ی data access و model را تعریف کنید و گفتیم اینها از نوع اسمبلی هستند.

اما غیر از نوع اسمبلی چند نوع دیگر داریم. اول این که خود اسمبلی چند نوع است. اسمبلی compile شده را توضیح دادیم، که می تواند یک dll آماده باشد که شما از اینترنت دانلود کرده باشید که می خواهید در برنامه تان استفاده کنید یا package nuget باشد یا این که dll سیستمی برای خود dotnetframework باشد مانند system.dll. اسمبلی ، compile نشده در اصل آن dll هایی هستند که شما کد برنامه تان را و کد وبسایت تان را در آنها می نویسید و آنها را compile کنید. اسمبلی nuget package مانند اسمبلی compile شده است، اما یک category است که شما مثلا assembly های nuget تان جدا باشد. در اینجا شما قابلیت دارید که بروید و از nuget یک package را دانلود کنید و از dll های آن استفاده کنید که اگر شد انشاالله در ویدئوهای بعدی توضیح می دهیم

و اسمبلی test جایی است که شما کد را تست می کنید اما کدهای test را کجا می نویسید. وقتی می خواهید کدهای داخل اسمبلی compile نشده را تان تست کنید باید از اسمبلی  نوع test استفاده کنید که اگر در اینجا ببینید یک منویی داریم به اسم اجرای یک unit test که می توانید اینجا تست هایتان را انجام دهید. پس این از نوع خود اسمبلی. غیر از نوع اسمبلی ، چهار نوع دیگر داریم فضای نام که همان name space است، کلاس که همان class های ما هستند، متدها method و خطوط کد که حالا می تواند یک کد باشد یا چند کد، شاید تعجب کنید که اینها در اینجا چه می کنند؟

اینها در اینجا هستند تا شما بتوانید دسترسی بدهید. حتی بر روی یک خط کد که به برنامه نویس های مختلف بتوانند یک خط کد را ویرایش کنند یا یک خط کد را بنویسند، یک متد یا یک کلاس یا یک name space که چندتا کلاس دارد و یا یک اسمبلی را شما در همه سطوح می توانید دسترسی بدهید. حالا من برای نمونه فرضا خودKS. Dynamic.UI.dll  اگر دقت کنید اولین زیرمجموعه های آن name space هستند. یعنی شما اگر KS.Dynamic.UI.dll => startup را انتخاب کنید می بینید که نوع آن فضای نام است.

سطح بعدی فضای نام ها حتما class هستند KS.Dynamic.UI.dll => controler یک کلاسی دارد به اسم test class حالا در اینجا می تواند n تا class داشته باشد.

اگر خود test class را انتخاب کنم می بینید از نوع خود class است. خود test class می تواند n تا متد داشته باشد که حالا در اینجا یک متد دارد من test method را انتخاب می کنم می بینیم از نوع method است و خود method که می تواند n تا line داشته باشد که الان در اینجا یک test line دارد. 

حالا شاید در اینجا برایتان سؤال پیش بیاید که من حتما باید این زیرمجموعه را رعایت کنم؟ نه شما تمام کدتان را می توانید در همین KS.Dynamic.UI.dll  بنویسید نیازی نیست که حتما name space , class , method و line را که اصلا نیازی نیست. این فقط برای test به شما گفته شده است که ما می توانیم در یک خط کد هم دسترسی بدهیم. اما توصیه این است که حداقل تا کلاس هایتان را تعریف کنید. یعنی یک dll داشته باشید، یک سری name space داشته باشد و هر name space هم تعدادی class داشته باشد. خوب است که تا اینجا را تعریف کنید اما اگر باز نخواستید تعریف کنید مشکلی ندارد شما همین KS.Dynamic.UI.dll  را که انتخاب کنید می بینید که می توانید از اول تا آخر همه ی کدها را در اینجا بنویسید. 

اما قسمت کد ، ببینید ما الان KS.Dynamic.UI.dll  را انتخاب کردیم ، 3 خط کد داره الان ، در قسمت اول ، خود Platform یک Platform owin Base که Owin مخفف Open web interface می باشد. من این را انشاءالله در ویدیوهای بعدی که مربوط به سورس  است خیلی کامل توضیح می دهم. فعلا با این یک خط کد کاری نداریم، اما دو خط کد دیگر هم اینجا هست یکی KS.Dynamic.UI.StartApp و KS.Dynamic.UI.Controller  اگر یادتان باشد دقیقا این دو تاNameSpace  این DLL هستند.

دو NameSpace که اینجا می بینید بین دو @ در اینجا آورده شده است. اما این ها چی هستند، من اگر یکی از این Name Space ها را انتخاب کنم مثل KS.Dynamic.UI.StartApp می بینید که یک قسمتی به نام نشانه ی جایگذاری در کد پدر را دارد که دقیقا همان کدی است که شما در dll دیدید این برای این است که چون قرار است برنامه نویس های متفاوتی کدهای شما را بنویسند شما از بالا یعنی برنامه نویسی که بالاتر قرار دارد Parent است می تواند بگوید کدی که برنامه نویس زیر مجموعه اش می نویسد ، کجای کد بالاتر تزریق شود. این جلوگیری می کند از تزریق کد توسط برنامه نویس که می خواهد روی کد شما خرابکاری ایجاد کند. برای امنیت کدنویسی شما است.

برنامه نویسی امن یکی از چالش های این Platform است. به وسیله ی یک نشانه گذاری در کد پدر شما می توانید برنامه نویسان زیرمجموعه ی خود را کنترل کنید که آن کدی که برای شما می نویسد دقیقا" کجای کد شما قرار است تزریق شود. در اینجا می بینید که Namespace ها قرار است که یک به یک مرتب زیر هم قرار بگیرند. هر Namespace نشانه ی جاگذاری در کد پدر خودش را دارد. من اگر الان فضای نام  KS.Dynamic.UI.Controller  را انتخاب کنم نشانه ی جای گذاری در کد پدرش اینجاست.

دقیقا همین اتفاق برای Namespace ها می افتد شما در اینجا می بینید یک نشانه ی جاگذاری برای Test class است. من اگر  Test class را انتخاب کنم می بینید که نشانه ی جاگذاری در کد پدرش Test class است. اینها را هم دقت داشته باشید که نمی شود تغییر داد برنامه نویسی که به اینجا دسترسی دارد و می تواند ویرایش کند اگر این را جابجا کند دیگر نمی تواند آن را ذخیره کند به او این پیغام را می دهد که چنین نشانه گذاری در کد پدر وجود ندارد اگر بگذارد مثلا بگذارد  1Test class ، نمی تواند این کار را انجام دهد .

این از خود ساختاری بود که شما می توانید کدتان را بنویسید. اما نکته ی بعدی اگر من در اینجا KS.Dynamic.UI.dll را انتخاب کنم در قسمت پایین یک دکمه ی Compile وجود دارد که دو حالت دارد؛ یکی Compile بدون ساخت وابستگی و Compile با ساخت وابستگی ها این به چه معنی است؟ یعنی حالت Rebuild All در Visual Studio می شود با ساخت وابستگی ها چون ممکن است کامپایل نشده ما وابسته باشد به یک سری dll کامپایل نشده دیگر. مثلا لایه ی UI تان به لایه ی Business تان وابسته است.

وقتی گزینه با ساخت وابستگی ها را انتخاب کنید برای لایه ی UI ، خود به خود لایه ی Business تان هم ساخته می شود و Reference می شود. بدون ساخت وابستگی ها دیگر آن dll  های رفرنس شده را کامپایل نمی کند و اگر کامپایل آن DLL ها وجود نداشته باشد ، حتما در اینجا خطا می گیرید فقط خود dll شما که compile می کنید فقط این را می سازد و آن dll های دیگر را اگر وجود داشته باشند را از شون استفاده می کنه. اما کدام ورژن استفاده می شود؟

این مهم است. ببینید اگر من dll Business را انتخاب کنم ما یک قسمتی داریم به نام نگارش قابل انتشار که الان برای Business انتخاب شده آخرین نگارشی که compile شده یا خواهد شد. این خواهد شد دقیقا موقع Rebuild All است ، چون ممکن است تا آن لحظه compile شده باشد. می گوید به محض این که compile شد از همان استفاده کن به عنوان رفرنس.

حالا در اینجا چون compile نشده است ورژن های قدیمی تر را نمی آورد اما اگر الان compile می شد مثلا در اینجا ورژن 1،2،3،4 داشت و شما می توانستید بگویید که حتما از ورژن 3 استفاده می کنید. مثلا 4 آن هنوز Stable نیست. برنامه نویس های دیگر که می خواهند از dll شما استفاده کنند فقط می توانند از ورژن 3 آن استفاده کنند. در اصل آن برنامه نویس dll است که می گوید از کدام ورژنی که من compile کرده ام باقی برنامه نویسان می توانند از آن ورژن رفرنس کنند و استفاده کنند.

این نگارش قابل انتشار فقط برای dll هایی که مکان ذخیرشون در output هست قابل استفاه هست و برای DLL با نام UI که از نوع ذخیره سازی در Bin است دیگر نگارش قابل انتقال ندارد. چرا ندارد؟ چون در اینجا یک دکمه ای داریم به نام مدیریت خروجی ها در اینجا خود یک دکمه انتشار دارد. یعنی dll که compile می شود در اینجا لیست ورژن هایش می آید و شما هرکدام از ورژن هایی که می خواهید انتشار دهید ، انتشار را می زنید که برود و در Bin وبسایت اما اگر مثلا dll با نام Data access را انتخاب کنم چون این هم از نوع Output است اولاً نگارش قابل انتقال دارد یعنی dll های دیگر را از کدام ورژن این استفاده کنم، چون در Output است نه Bin و مدیریت خروجی ها را هم بزنم در اینجا می بینید که دکمه ی انتشار ندارد چون انتشار برای نوع dll هایی که در Output هستند بی معنی است.

یک نکته ی دیگر اگر من مثلا KS.Dynamic.UI.dll را انتخاب کنم مثلا Namespace Controller یک تفاوت کد نویسی با visual Studio این است که شما وقتی که Namespace را می نویسید visual studio معمولا این using ها را می گذارد بالای Namespace ، ولی اینجا using ها حتما باید داخل Namespace باشند. اگر نگذاریم و اینها را بگذاریم بالای Namespace هم ممکن است مشکلی پیش نیاید ولی اگر چند Namespace داشته باشیم ممکن است using ها با هم اختلال پیدا کنند. برای این که از این اختلال جلوگیری کنیم بهتر و توصیه شده است که برعکس visual studio که using ها بالای Namespace هستند using های هر Namespace را بگذاریم داخل خود Namespace. این تنها تفاوتی است که با کد نویسی visual studio دارد.