اعمال شرط روی ردیف
- اگر منابع داده فعلی آن نیاز شما را برآورده نمیکنند، یک منبع داده جدید بنویسید. یکی از این منابع داده نهایتا برای تامین اطلاعات ردیفها استفاده میشوند.
+ در این پروژه امکان دسترسی به یک سری رخداد در حین اضافه شدن سلولها و ردیفها وجود دارد.
مثال رخدادها و یک نمونه دیگر از کاربرد رخدادها در حین کار با گروهها و یا نمونهای برای تزریق ردیفهای جدید به گزارش. مثالی در مورد گزارشهای حسابداری جهت نگهداری مقادیر ردیفهای قبلی.
ضمن تشکر. جهت یادگیری میپرسم. اگرچه که AutoMapper میتونه مشکل را حل کنه ولی تمام ستون های مورد نیازم رو باید در configuration تعریف کنم. آیا اگر خودم بتونم یک Selector مانند نمونه زیر ایجاد کنم بهتر نیست؟ دلیل این کار کاهش وابستگی و راندمان بیشتره. آیا ایجاد Selectorی مانند زیر این دو هدف را برآورده میکنه؟
private static Expression<Func<LineJoint, Models.Output.Piping.LineJoints.LineJoint2>> Selector() { //if (Condition()) // return x => new Models.Output.Piping.LineJoints.LineJoint2 // { // .... // }; return x => new Models.Output.Piping.LineJoints.LineJoint2 { Id = x.Id, JointNo = x.JointNo }; }
در نتیجه میتونم query را بصورت زیر اجرا کنم:
var result = await query.Select(Selector()).ToListAsync();
آیا به یادگیری یا ادامهی استفاده از AngularJS خواهید پرداخت؟
در نگاه اول شاید برای توسعه دهندگان مبتدی یک سری مباحث گیج کننده باشن و خیلی از قابلیتها هم جادویی و جذاب. اما حقیقت امر این است که code base این فریم ورک مشکلات شگفت آوری داره. چند ساعت وقت گذاشتن روی اینترنت کافی هست تا از تمام جنبهها فریم ورکهای مطرح رو بررسی کرد و متوجه شد که Angular چقدر مشکلات اساسی داره. بصورت تیتر وار چند مورد رو لیست میکنم:
- Dynamic Scoping, and scope inheritance
- Two-way data binding with $watchers
- The $digest cycle
- No DOM manipulation capabilities
- Finite Routing, unless you use a 3rd party like ui-router
- app logic and structure expressed in HTML
- No server-side rendering (mostly for speed boost and SEO)
- string-based Dependency Injection
- Ill-Conceived architecture (obsolete constructor functions etc)
- Debugging issues
- Re-defining well established terminology
- Syntactic Sugar
- Execution Contexts
- Unnecessary Complications
- Incompatible with 3rd party libraries, like jQuery etc.
- Sparse documentation with literally no real-world examples
و مواردی از این دست. شاید برای پروژههای کوچک این فریم ورک مناسب باشه اما قطعا برای پروژههای بزرگی که قرار است برای مدتی طولانی توسعه داده بشن و نگهداری بشن اصلا انتخاب درستی نیست. حتی اگر پروژههای بزرگی هم با موفقیت توسط این فریم اجرا شده باشه باز هم ماهیت مساله تغییر نمیکنه.
در حال حاظر بین فریم ورکهای دیگه بهترین انتخاب Ember هست که بسیاری از مشکلات ذکر شده رو نداره و ساختار و معماری قوی و خوبی هم داره. Backbone و Durandal هم فریم ورکهای قوی ای هستند ولی تفاوتهای نسبتا زیادی با Ember دارن.
حائز اهمیت این که، اپلیکیشنهای SPA جوان هستند و فعلا همه جای دنیا در حال آزمایش و بررسی این هستند که چطور میشه چنین پروژه هایی رو اجرا کرد و کدام راه بهترین راه هست، بنابراین تا به استانداردهای ثابتی برسیم راه طولانی ای در پیش داریم. از طرفی بزودی استاندارد جدید جاوا اسکریپت (ECMA6) منتشر میشه، که با انتشارش فریم ورک هایی مثل Ember و Angular رو کاملا به هم خواهد ریخت. مثلا در نسخه جدید آبجکتهای Observable خواهیم داشت. بنابراین متدهای Angular و Ember برای تشخیص تغییرات به کلی بلا استفاده خواهند بود و بازنویسیهای اساسی لازم میشود.
EF Code First #2
یک: ASP.NET Core مستقل از Platform است
دو: Open Source است
سه: جدا بودن از Web Server
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) تو کار
// 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های مدرن سمت کلاینت
- bundle و minify کردن فایلهای جاوا اسکریپت و همینطور CSS
- اجرای ابزارهایی برای bundle و minify کردن قبل از هر build
- کامپایل کردن فایلهای LESS و SASS در CSS
- کامپیال کردن فایلهای CoffeeScript و TypeScript در JavaScript
نشانه های طراحی ضعیف
برای آنکه طراحی قوی و درست را یاد بگیریم، لازم است که نشانههای طراحی ضعیف را بدانیم. این نشانهها عبارتند از:
۱- Rigidity (انعطاف ناپذیری): یک ماژول انعطاف ناپذیر است، اگر یک تغییر در آن، منجر به تغییرات در سایر ماژولها گردد. هر چه میزان تغییرات آبشاری بیشتر باشد، نرم افزار خشکتر و غیر منعطفتر است.
۲- Fragility (شکنندگی): وقتی که تغییر در قسمتی از نرم افزار باعث به بروز اشکال در بخشهای دیگر شود.
۳- Immobility (تحرک ناپذیری): وقتی نتوان قسمت هایی از نرم افزار را در جاهای دیگر استفاده نمود و یا به کار گیری آن هزینه و ریسک بالایی داشته باشد.
۴- Viscosity (لزجی): وقتی حفظ طراحی اصولی پروژه مشکل باشد، میگوییم پروژه لزج شده است. به عنوان مثال وقتی تغییری در پروژه به دو صورت اصولی و غیر اصولی قابل انجام باشد و روش غیر اصولی راحتتر باشد، میگوییم لزج شده است. البته لزجی محیط هم وجود دارد مثلا انجام کار به صورت اصولی نیاز به Build کل پروژه دارد که زیاد طول میکشد.
۵- Needless Complexity (پیچیدگی اضافی): زمانی که امکانات بدون استفاده در نرم افزار قرار گیرند.
۶- Needless Repetition (تکرارهای اضافی): وقتی که کدهایی با منطق یکسان در جاهای مختلف برنامه کپی میشوند، این مشکلات رخ میدهند.
۷- Opacity (ابهام): وقتی که فهمیدن یک ماژول سخت شود، رخ میدهد و کد برنامه مبهم بوده و قابل فهم نباشد.
چرا نرم افزار تمایل به پوسیدگی دارد؟
در روشهای غیر چابک یکی از دلایل اصلی پوسیدگی، عدم تطابق نرم افزار با تغییرات درخواستی است. لازم است که این تغییرات به سرعت انجام شوند و ممکن است که توسعه دهندگان از طراحی ابتدایی اطلاعی نداشته باشند. با این حال ممکن است تغییرایی قابل انجام باشد ولی برخی از آنها طراحی اصلی را نقض میکنند. ما نباید تغییرات نیازمندیها را مقصر بدانیم. باید طراحی ما قابلیت تطبیق با تغییرات را داشته باشد.
یک تیم چابک از تغییرات استقبال میکند. وقت بسیار کمی را روی طراحی اولیه کل کار میگذارد و سعی میکند که طراحی سیستم را تا جایی که ممکن است ساده و تمیز نگه دارد با استفاده از تستهای واحد و یکپارچه از آن محافظت کند. این طراحی را انعطاف پذیر میکند. تیم از قابلیت انعطاف پذیری برای بهبود همیشگی طراحی استفاده میکند. بنابراین در هر تکرار نرم افزاری خواهیم داشت که نیازمندیهای آن تکرار را برآورده میکند.
پاسخ : هیچکدام!
برای نمونه دو مورد از محصولات مهم تجاری و پر درآمد مایکروسافت در مقیاس سازمانی SharePoint و Exchange server هستند (البته اینجا منظور برنامه web access مربوط به Exchange server است). جالب اینجا است که هر دو محصول، مبتنی بر دات نت فریم ورک سه و نیم بوده و از ASP.Net WebForms استفاده میکنند. تفاوت مهم آنها با نگارش سال 2007 هر کدام، استفاده از ASP.Net Ajax مایکروسافت در این محصولات است و همچنین استفادهی وسیع از توانمندیهای پاورشل 2 خصوصا امکان مدیریت از راه دور پاور شل 2 که برای مثال در برنامه web access مربوط به exchange server 2010 ، امکان مدیریت خود exchange server را نیز فراهم آورده است یا در SharePoint 2010 جایگزین stsadm شده است (هر چند stsadm هنوز موجود است اما منسوخ شده در نظر گرفته میشود).
به علاوه هر دو محصول فقط با ویندوزهای سرور 2008 به بعد، آن هم نسخهی 64 بیتی کار میکنند. (البته از آنجائیکه هستهی ویندوز 7 با هستهی ویندوز سرور 2008 نگارش R2 یکی است (یا حداقل بر مبنای یک code base هستند)، SharePoint 2010 را بر روی ویندوز 7 شصت و چهار بیتی هم میتوان جهت آزمایش و توسعه نصب کرد)
یک دورهی مدیریتی SharePoint 2010 را میتوانید در آدرس زیر مشاهده نمائید:
Microsoft SharePoint 2010 Administration
جهت اثبات این مدعا (استفاده از WebForms و نه MVC) دو تصویر ذیل به اندازهی کافی گویا هستند:
شیرپوینت 2010
Web Access در Exchange server 2010
جلسه اول:
اولین قدم در تولید و توسعه نرم افزار داشتن یک نگرش سیستمی به بسته یا محصول نرم افزاری میباشد. اما چرا ما باید نرم افزار را به عنوان یک سیستم در نظربگیریم ؟
جواب این سئوال را باید از تعریف تئوری سیستم و خصوصیاتی که یک سیستم دارا میباشد استخراج کنیم.
تئوری سیستمها
دانشی برای سهولت کار با سیستمها و بررسی دقیق این مفهوم است ؛ در واقع تئوری سیستمها روشی برای شناخت محیط اطراف یا روشی برای شناخت دنیای واقع میباشد .
از تعریف فوق میتوان نتیجه گرفت :
برنامه نویسان برای ساخت برنامه هایی که با نیاز کاربران همسو باشد ، نیاز به شناخت محیطی دارند که کاربران در آن فعالیت میکنند پس برای شناخت محیط باید با دید سیستمی به مسئله نگاه کرد.
خصوصیات مهم سیستم :
1. محیط – Environment: هر سیستم در یک محیط قرار دارد.
2. مرز – Boundary : سیستمهای موجود در یک محیط توسط مرزها از یکدیگر جدا میشوند.
3. ورودی و خروجی – I/O : هر سیستم ورودی هایی را از محیط میگیرد و خروجی هایی را به محیط پس میدهد.
4. واسط – Interface : امکان محاوره سیستمها در یک محیط را فراهم میکند.
5. زیر سیستم – Sub System : هر سیستم میتواند حاوی چندین زیرسیستم باشد . زیر سیستمها تمام خصوصیتهای یک سیستم را دارا میباشند.
6. مکانیزم کنترلی – Controller : مهمترین بخش یک سیستم میباشد. مکانیزم کنترلی در واقع کنترل کننده تمامی فعالیتهای انجام شده توسط یک سیستم است . ورودیها از طریق مکانیزم کنترلی دریافت میشود و بر اساس آن خروجی هایی به محیط پس داده میشود.
نتیجه گیری :
با توجه به خصوصیاتی که در مورد سیستمها مطرح شد به راحتی میتوانیم دلیل علاقه مندی برنامه -نویسان به نوع نگرش سیستمی را در یابیم ، و جود محیط پیرامون یک سیستم و نحوه تبادل اطلاعات این سیستم با سایر سیستمها در این محیط ، شکستن یک سیستم به چند زیر سیستم برای راحتی مسئله و پیاده سازی آسانتر آن و نیز وجود اینترفیسها برای برقراری محاوره ای استاندارد بین زیر سیستمهای یک سیستم و همچنین وجود ورودی هاو تصمیم گیری براساس ورودی هاو تولید یک خروجی همه و همه از نکات مورد توجه برنامه نویسان در تولید یک بسته نرم افزاری هستند که هماهنگی کاملی با مفاهیم تئوری سیستمها دارند.