غنی سازی کامپایلر C# 9.0 با افزونهها
Roslyn analyzers به همراه پیشنهادهایی در مورد code styles هم هستند؛ برای مثال توصیهی به استفادهی از var و یا عکس آن. میتوان این توصیهها را تبدیل به اجبار هم کرد تا در یک تیم، code styles یکدستی ارائه شود و روش آن، وارد کردن این توصیهها به پروسهی build است. برای اینکار میتوان فایل csproj را به نحو زیر ویرایش کرد:
<PropertyGroup> <TargetFramework>net6.0</TargetFramework> <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild> </PropertyGroup>
[*.cs] # Default severity for analyzer diagnostics with category 'Style' (escalated to build warnings) dotnet_analyzer_diagnostic.category-Style.severity = warning
بدیهی است در این صورت، روش لغو توصیهی خاصی به صورت زیر است:
dotnet_diagnostic.IDE0008.severity = none
انتشار ویژوال استدیو ۲۰۲۲ نگارش 17.5
For .NET and cloud developers, we’ve focused on improving the inner-loop dev experience. New .http/.rest files make it easier to test and iterate on your APIs directly in Visual Studio, while improved Dev Tunnels help streamline the configuration and management of your webhooks. We’ve also made it easier than ever to deploy your ASP.NET apps to containers.
Game developers can now view properties from base classes modified in an Unreal Blueprint asset without leaving the IDE. Visual Studio has improved the cross-platform development experience with a new remote file explorer, Linux Console output to the Integrated Terminal window, dev container improvements, and more.
Beyond individuals, Visual Studio also has new features to better support dev teams at scale, with exportable configuration files and a persistent update toggle helping ensure everyone on your team is working from the latest version of the tool.
This blog covers several of the top new features in Visual Studio 17.5—to see some in action, watch the Visual Studio 17.5 release video. As always lot of these features come straight from your feedback and suggestions. Your feedback is critical to help us make Visual Studio the best tool it can be!
آشنایی با نحوه ایجاد یک IoC Container
IoC Container چیست؟
IoC Container، فریم ورکی است برای انجام تزریق وابستگیها. در این فریم ورک امکان تنظیم اولیه وابستگیهای سیستم وجود دارد. برای مثال زمانیکه برنامه از یک IoC Container، نوع اینترفیس خاصی را درخواست میکند، این فریم ورک با توجه به تنظیمات اولیهاش، کلاسی مشخص را بازگشت خواهد داد.
IoC Containerهای قدیمیتر، برای انجام تنظیمات اولیه خود از فایلهای کانفیگ استفاده میکردند. نمونههای جدیدتر آنها از روشهای Fluent interfaces برای مشخص سازی تنظیمات خود بهره میبرند.
زمانیکه از یک IOC Container در کدهای خود استفاده میکنید، مراحلی چند رخ خواهند داد:
الف) کد فراخوان، از IOC Container، یک شیء مشخص را درخواست میکند. عموما اینکار با درخواست یک اینترفیس صورت میگیرد؛ هرچند محدودیتی نیز نداشته و امکان درخواست یک کلاس از نوعی مشخص نیز وجود دارد.
ب) در ادامه IOC Container به لیست اشیاء قابل ارائه توسط خود نگاه کرده و در صورت وجود، وهله سازی شیء درخواست شده را انجام و نهایتا شیء مطلوب را بازگشت خواهد داد.
در این بین زنجیرهی وابستگیهای مورد نیاز نیز وهله سازی خواهند شد. برای مثال اگر وابستگی اول به وابستگی دوم برای وهله سازی نیاز دارد، کار وهله سازی وابستگیهای وابستگی دوم نیز به صورت خودکار انجام خواهند شد. (این موردی است که بسیاری از تازه واردان به این بحث تا یکبار آنرا امتحان نکنند باور نخواهند کرد!)
ج) سپس کد فراخوان وهله دریافتی را مورد پردازش قرار داده و سپس شروع به استفاده از متدها و خواص آن خواهد نمود.
در تصویر فوق محل قرارگیری یک IOC Container را مشاهده میکنید. یک IOC Container در مورد تمام وابستگیهای مورد نیاز، اطلاعات لازم را دارد. همچنین این فریم ورک در مورد کلاسی که قرار است از وابستگیهای سیستم استفاده نماید نیز مطلع است؛ به این ترتیب میتواند به صورت خودکار در زمان وهله سازی آن، نوعهای وابستگیهای مورد نیاز آنرا در اختیارش قرار دهد.
برای مثال در اینجا MyClass، وابستگی مشخص شده در سازنده خود را به نام IDependency از IOC Container درخواست میکند. سپس این IOC Container بر اساس تنظیمات اولیه خود، یکی از وابستگیهای A یا B را بازگشت خواهد داد.
آغاز به کار ساخت یک IOC Container نمونه
در ابتدا کدهای آغازین مثال بحث جاری را در نظر بگیرید:
using System; namespace DI01 { public interface ICreditCard { string Charge(); } public class Visa : ICreditCard { public string Charge() { return "Charging with the Visa!"; } } public class MasterCard : ICreditCard { public string Charge() { return "Swiping the MasterCard!"; } } public class Shopper { private readonly ICreditCard creditCard; public Shopper(ICreditCard creditCard) { this.creditCard = creditCard; } public void Charge() { var chargeMessage = creditCard.Charge(); Console.WriteLine(chargeMessage); } } }
var shopper = new Shopper(new Visa()); shopper.Charge();
using System; using System.Collections.Generic; using System.Linq; namespace DI01 { public class Resolver { //کار ذخیره سازی و نگاشت از یک نوع به نوعی دیگر در اینجا توسط این دیکشنری انجام خواهد شد private Dictionary<Type, Type> dependencyMap = new Dictionary<Type, Type>(); /// <summary> /// یک نوع خاص از آن درخواست شده و سپس بر اساس تنظیمات برنامه، کار وهله سازی /// نمونه معادل آن صورت خواهد گرفت /// </summary> public T Resolve<T>() { return (T)Resolve(typeof(T)); } private object Resolve(Type typeToResolve) { Type resolvedType; // ابتدا بررسی میشود که آیا در تنظیمات برنامه نگاشت متناظری برای نوع درخواستی وجود دارد؟ if (!dependencyMap.TryGetValue(typeToResolve, out resolvedType)) { //اگر خیر، کار متوقف خواهد شد throw new Exception(string.Format("Could not resolve type {0}", typeToResolve.FullName)); } var firstConstructor = resolvedType.GetConstructors().First(); var constructorParameters = firstConstructor.GetParameters(); // در ادامه اگر این نوع، دارای سازندهی بدون پارامتری است // بلافاصله وهله سازی خواهد شد if (!constructorParameters.Any()) return Activator.CreateInstance(resolvedType); var parameters = new List<object>(); foreach (var parameterToResolve in constructorParameters) { // در اینجا یک فراخوانی بازگشتی صورت گرفته است برای وهله سازی // خودکار پارامترهای مختلف سازنده یک کلاس parameters.Add(Resolve(parameterToResolve.ParameterType)); } return firstConstructor.Invoke(parameters.ToArray()); } public void Register<TFrom, TTo>() { dependencyMap.Add(typeof(TFrom), typeof(TTo)); } } }
var resolver = new Resolver(); //تنظیمات اولیه resolver.Register<Shopper, Shopper>(); resolver.Register<ICreditCard, Visa>(); //تزریق وابستگیها و وهله سازی var shopper = resolver.Resolve<Shopper>(); shopper.Charge();
ابتدا کار تعاریف نگاشتهای اولیه انجام میشود. در این صورت زمانیکه متد Resolve فراخوانی میگردد، نوع درخواستی آن به همراه سازنده دارای آرگومانی از نوع ICreditCard وهله سازی شده و بازگشت داده خواهد شد. سپس با در دست داشتن یک وهله آماده، متد Charge آنرا فراخوانی خواهیم کرد.
بررسی نحوه استفاده از Microsoft Unity به عنوان یک IoC Container
Unity چیست؟
Unity یک فریم ورک IoC Container تهیه شده توسط مایکروسافت میباشد که آنرا به عنوان جزئی از Enterprise Library خود قرار داده است. بنابراین برای دریافت آن یا میتوان کل مجموعه Enterprise Library را دریافت کرد و یا به صورت مجزا به عنوان یک بسته نیوگت نیز قابل تهیه است.
برای این منظور در خط فرمان پاورشل نیوگت در VS.NET دستور ذیل را اجرا کنید:
PM> Install-Package Unity
پیاده سازی مثال خریدار توسط Unity
همان مثال قسمت قبل را درنظر بگیرید. قصد داریم اینبار بجای IoC Container دست سازی که تهیه شد، پیاده سازی آنرا به کمک MS Unity انجام دهیم.
using Microsoft.Practices.Unity; namespace DI02 { class Program { static void Main(string[] args) { var container = new UnityContainer(); container.RegisterType<ICreditCard, MasterCard>(); var shopper = container.Resolve<Shopper>(); shopper.Charge(); } } }
مطابق کدهای فوق، ابتدا تنظیمات IoC Container انجام شده است. به آن اعلام کردهایم که در صورت نیاز به ICreditCard، نوع MasterCard را یافته و وهله سازی کن. با این تفاوت که Unity هوشمندتر بوده و سطر مربوط به ثبت کلاس Shoper ایی را که در قسمت قبل انجام دادیم، در اینجا حذف شده است.
سپس به این IoC Container اعلام کردهایم که نیاز به یک وهله از کلاس خریدار داریم. در اینجا Unity کار وهله سازیهای خودکار وابستگیها و تزریق آنها را در سازنده کلاس خریدار انجام داده و نهایتا یک وهله قابل استفاده را در اختیار ادامه برنامه قرار خواهد داد.
یک نکته:
به صورت پیش فرض کار تزریق وابستگیها در سازنده کلاسها به صورت خودکار انجام میشود. اگر نیاز به Setter injection و مقدار دهی خواص کلاس وجود داشت میتوان به نحو ذیل عمل کرد:
container.RegisterType<ICreditCard, MasterCard>(new InjectionProperty("propertyName", 5));
مدیریت طول عمر اشیاء در Unity
توسط یک IoC Container میتوان یک وهله معمولی از شیءایی را درخواست کرد و یا حتی طول عمر این وهله را به صورت Singleton معرفی نمود (یک وهله در طول عمر کل برنامه). در Unity اگر تنظیم خاصی اعمال نشود، هربار که متد Resolve فراخوانی میگردد، یک وهله جدید را در اختیار ما قرار خواهد داد. اما اگر پارامتر متد RegisterType را با وهلهای از ContainerControlledLifetimeManager مقدار دهی کنیم:
container.RegisterType<ICreditCard, MasterCard>(new ContainerControlledLifetimeManager());
حالت پیش فرض مورد استفاده، بدون ذکر پارامتر متد RegisterType، مقدار TransientLifetimeManager میباشد.
- بررسی ویرویس Stuxnet | www.idevcenter.com
- تایپ متن فارسی در Gmail | googlepersianblog.blogspot.com
- خصوصیات جدید در ASP.NET 4.5 - خصوصیت HTML Editor Smart Tasks and Event Handler Generation | mojtabasahraei.blogfa.com
- دیتابیس رنگی | www.dotnetdev.info
- شما مرغابی هستید یا عقاب؟ | hrnews.blogfa.com
- نقد فیلم "one flew over the cuckoos nest - دیوانه از قفس پرید( پرواز بر فراز آشیانه فاخته)" | filmhafteh.blogfa.com
- Addressing Visual Studio performance | blogs.msdn.com
- BUILD conference–day 3 | lostechies.com
- BUILD: WinRT, Silverlight, WPF, XAML | www.japf.fr
- C# and Visual Basic on the WinRT API | www.infoq.com
- Multi Monitor in VS.NET 2010 & SQL Server 2011 | www.nikamooz.com
- My List of Must-See Build 2011 Videos | 10rem.net
- New CSS editor features in Visual Studio 11 Developer Preview | blogs.msdn.com
- New Tools and New Content - ASP.NET, Visual Studio 11 Web and .NET 4.5 Developer Preview (with commentary) | www.hanselman.com
- Prototype xUnit.net Visual Studio 11 Unit Testing Plugin | bradwilson.typepad.com
- RIA Services updates for //build | feeds.jeffhandley.com
- Using WinRT from .NET | ermau.com
- Windows 8 and WinRT: Links, News and Resources | ajlopez.wordpress.com
- Windows 8 Replaces the Win32 API | www.infoq.com
- Windows 8: What you Need to Know | csharperimage.jeremylikness.com
- WinRT: An Object Orientated Replacement for Win32 | www.infoq.com
سری طراحی بهتر برنامههای #C
پایه و اساس
عموما این باور وجود دارد که با استفاده از الگوی Repository میتوانید (در مجموع) دسترسی به دادهها را از لایه دامنه (Domain) تفکیک کنید و "دادهها را بصورت سازگار و استوار عرضه کنید".اگر به هر کدام از پیاده سازیهای الگوی Repository در کنار (UnitOfWork (EF دقت کنید خواهید دید که تفکیک (decoupling) قابل ملاحظه ای وجود ندارد.
using System; using System.Collections.Generic; using System.Linq; using System.Data; using ContosoUniversity.Models; namespace ContosoUniversity.DAL { public class StudentRepository : IStudentRepository, IDisposable { private SchoolContext context; public StudentRepository(SchoolContext context) { this.context = context; } public IEnumerable<Student> GetStudents() { return context.Students.ToList(); } public Student GetStudentByID(int id) { return context.Students.Find(id); } //<snip> public void Save() { context.SaveChanges(); } } }
این کلاس بدون SchoolContext نمیتواند وجود داشته باشد، پس دقیقا چه چیزی را در اینجا decouple کردیم؟ هیچ چیز را!
در این قطعه کد - از MSDN - چیزی که داریم یک پیاده سازی مجدد از LINQ است که مشکل کلاسیک Repository APIهای بی انتها را بدست میدهد. منظور از Repository APIهای بی انتها، متدهای جالبی مانند GetStudentById, GetStudentByBirthday, GetStudentByOrderNumber و غیره است.
اما این مشکل اساسی نیست. مشکل اصلی روتین ()Save است. این متد یک دانش آموز (Student) را ذخیره میکند .. اینطور بنظر میرسد. دیگر چه چیزی را ذخیره میکند؟ آیا میتوانید حدس بزنید؟ من که نمیتوانم .. بیشتر در ادامه.
UnitOfWork تراکنشی است
یک UnitOfWork همانطور که از نامش بر میآید برای انجام کاری وجود دارد. این کار میتواند به سادگی واکشی اطلاعات و نمایش آنها، و یا به پیچیدگی پردازش یک سفارش جدید باشد. هنگامی که شما از EntityFramework استفاده میکنید و یک DbContext را وهله سازی میکنید، در واقع یک UnitOfWork میسازید.در EF میتوانید با فراخوانی ()SubmitChanges تمام تغییرات را فلاش کرده و بازنشانی کنید (flush and reset). این کار بیتهای مقایسه change tracker را تغییر میدهد. افزودن رکوردهای جدید، بروز رسانی و حذف آنها. هر چیزی که تعیین کرده باشید. و تمام این دستورات در یک تراکنش یا Transaction انجام میشوند.
یک Repository مطلقا یک UnitOfWork نیست
هر متد در یک Repository قرار است فرمانی اتمی (Atomic) باشد - چه واکشی اطلاعات و چه ذخیره آنها. مثلا میتوانید یک Repository داشته باشید با نام SalesRepository که اطلاعات کاتالوگ شما را واکشی میکند، و یا یک سفارش جدید را ثبت میکند. منظور از فرمانهای اتمیک این است، که هر متد تنها یک دستور را باید اجرا کند. تراکنشی وجود ندارد و امکاناتی مانند ردیابی تغییرات و غیره هم جایی ندارند.
یکی دیگر از مشکلات استفاده از Repositoryها این است که بزودی و به آسانی از کنترل خارج میشوند و نیاز به ارجاع دیگر مخازن پیدا میکنند. به دلیل اینکه مثلا نمیدانستید که SalesRepository نیاز به ارجاع ReportRepository داشته است (یا چیزی مانند این).
این مشکل به سرعت مشکل ساز میشود، و نیز به همین دلیل است که به UnitOfWork تمایل پیدا میکنیم.
بدترین کاری که میتوانید انجام دهید: <Repository<T
این الگو دیوانه وار است. این کار عملا انتزاعی از یک انتزاع دیگر است (abstraction of an abstraction). به قطعه کد زیر دقت کنید، که به دلیلی نامشخص بسیار هم محبوب است.public class CustomerRepository : Repository < Customer > { public CustomerRepository(DbContext context){ //a property on the base class this.DB = context; } //base class has Add/Save/Remove/Get/Fetch }
در نگاه اول شاید بگویید مشکل این کلاس چیست؟ همه چیز را کپسوله میکند و کلاس پایه Repository هم به کانتکست دسترسی دارد. پس مشکل کجاست؟
مشکلات عدیده اند .. بگذارید نگاهی بیاندازیم.
آیا میدانید این DbContext از کجا آمده است؟
خیر، نمیدانید. این آبجکت به کلاس تزریق (Inject) میشود، و نمیدانید که چه متدی آن را باز کرده و به چه دلیلی. ایده اصلی پشت الگوی Repository استفاده مجدد از کد است. بدین منظور که مثلا برای عملیات CRUD از کلاسی پایه استفاده کنید تا برای هر موجودیت و فرمی نیاز به کدنویسی مجدد نباشد. برگ برنده این الگو نیز دقیقا همین است. مثلا اگر بخواهید از کدی در چند فرم مختلف استفاده کنید از این الگو استفاده میشد.
الگوی UnitOfWork همه چیز در نامش مشخص است. اگر قرار باشد آنرا بدین شکل تزریق کنید، نمیتوانید بدانید که از کجا آمده است.
شناسه مشتری جدید را نیاز داشتم
کد بالا در CustomerRepository را در نظر بگیرید - که یک مشتری جدید را به دیتابیس اضافه میکند. اما CustomerID جدید چه میشود؟ مثلا به این شناسه نیاز دارید تا یک log بسازید. چه میکنید؟ گزینههای شما اینها هستند:
- متد ()SubmitChanges را صدا بزنید تا تغییرات ثبت شوند و بتوانید به CustomerID جدید دسترسی پیدا کنید
- CustomerRepository خود را باز کنید و متد پایه Add را بازنویسی (override) کنید. بدین منظور که پیش از بازگشت دادن، متد ()SubmitChanges را فراخوانی کند. این راه حلی است که MSDN به آن تشویق میکند، و بمبی ساعتی است که در انتظار انفجار است
- تصمیم بگیرید که تمام متدهای Add/Remove/Save در مخازن شما باید ()SubmitChanges را فراخوانی کنند
مشکل را میبینید؟ مشکل در خود پیاده سازی است. در نظر بگیرید که چرا New Customer ID را نیاز دارید؟ احتمالا برای استفاده از آن در ثبت یک سفارش جدید، و یا ثبت یک ActivityLog.
اگر بخواهیم از StudentRepository بالا برای ایجاد دانش آموزان جدید پس از خرید آنها از فروشگاه کتاب مان استفاده کنیم چه؟ اگر DbContext خود را به مخزن تزریق کنید و دانش آموز جدید را ذخیره کنید .. اوه .. تمام تراکنش شما فلاش شده و از بین رفته!
حالا گزینههای شما اینها هستند: 1) از StudentRepository استفاده نکنید (از OrderRepository یا چیز دیگری استفاده کنید). و یا 2) فراخوانی ()SubmitChanges را حذف کنید و به باگهای متعددی اجازه ورود به کد تان را بدهید.
اگر تصمیم بگیرید که از StudentRepository استفاده نکنید، حالا کدهای تکراری (duplicate) خواهید داشت.
شاید بگویید که برای دستیابی به شناسه رکورد جدید نیازی به ()SubmitChanges نیست، چرا که خود EF این عملیات را در قالب یک تراکنش انجام میدهد!
دقیقا درست است، و نکته من نیز همین است. در ادامه به این قسمت باز خواهیم گشت.
متدهای Repositories قرار است اتمیک باشند
به هر حال تئوری اش که چنین است. چیزی که در Repositoryها داریم حتی اصلا Repository هم نیست. بلکه یک abstraction برای عملیات CRUD است که هیچ کاری مربوط به منطق تجاری اپلیکیشن را هم انجام نمیدهد. مخازن قرار است روی دستورات مشخصی تمرکز کنند (مثلا ثبت یک رکورد یا واکشی لیستی از اطلاعات)، اما این مثالها چنین نیستند.
همانطور که گفته شده استفاده از چنین رویکردهایی به سرعت مشکل ساز میشوند و با رشد اپلیکیشن شما نیز مشکلات عدیده ای برایتان بوجود میآروند.
خوب، راه حل چیست؟
برای جلوگیری از این abstractionهای غیر منطقی دو راه وجود دارد. اولین راه استفاده از Command/Query Separation است که ممکن است در ابتدا کمی عجیب و بنظر برسند اما لازم نیست کاملا CQRS را دنبال کنید. تنها از سادگی انجام کاری که مورد نیاز است لذت ببرید، و نه بیشتر.
آبجکتهای Command/Query
Jimmy Bogard مطلب خوبی در اینباره نوشته است و با تغییراتی جزئی برای بکارگیری Properties کدی مانند لیست زیر خواهیم داشت. مثلا برای مطالعه بیشتر درباره آبجکتهای Command/Query به این لینک سری بزنید.
public class TransactOrderCommand { public Customer NewCustomer {get;set;} public Customer ExistingCustomer {get;set;} public List<Product> Cart {get;set;} //all the parameters we need, as properties... //... //our UnitOfWork StoreContext _context; public TransactOrderCommand(StoreContext context){ //allow it to be injected - though that's only for testing _context = context; } public Order Execute(){ //allow for mocking and passing in... otherwise new it up _context = _context ?? new StoreContext(); //add products to a new order, assign the customer, etc //then... _context.SubmitChanges(); return newOrder; } }
DataContext خود را در آغوش بگیرید
ایده ای که در ادامه خواهید دید را شخصا بسیار میپسندم (که توسط Ayende معرفی شد). چیزهایی که به آنها نیاز دارید را در قالب یک فیلتر wrap کنید و یا از یک کلاس کنترلر پایه استفاده کنید (با این فرض که از اپلیکیشنهای وب استفاده میکنید).using System; using System.Web.Mvc; namespace Web.Controllers { public class DataController : Controller { protected StoreContext _context; protected override void OnActionExecuting(ActionExecutingContext filterContext) { //make sure your DB context is globally accessible MyApp.StoreDB = new StoreDB(); } protected override void OnActionExecuted(ActionExecutedContext filterContext) { MyApp.StoreDB.SubmitChanges(); } } }
این کار به شما اجازه میدهد که از DataContext خود در خلال یک درخواست واحد (request) استفاده کنید. تنها کاری که باید بکنید این است که از این کلاس پایه ارث بری کنید. این بدین معنا است که هر درخواست به اپلیکیشن شما یک UnitOfWork خواهد بود. که بسیار هم منطقی و قابل قبول است. در برخی موارد هم شاید این فرض درست یا کارآمد نباشد، که در این هنگام میتوانید از آبجکتهای Command/Query استفاده کنید.
ایدههای بعدی: چه چیزی بدست آوردیم؟
چیزهای متعددی بدست آوردیم.- تراکنشهای روشن و صریح: دقیقا میدانیم که DbContext ما از کجا آمده و در هر مرحله روی چه UnitOfWork ای کار میکنیم. این امر هم الان، و هم در آینده بسیار مفید خواهد بود
- انتزاع کمتر == شفافیت بیشتر: ما Repositoryها را از دست دادیم، که دلیلی برای وجود داشتن نداشتند. به جز اینکه یک abstraction از abstraction دیگر باشند. رویکرد آبجکتهای Command/Query تمیزتر است و دلیل وجود هرکدام و مسئولیت آنها نیز روشنتر است
- شانس کمتر برای باگ ها: رویکردهای مبتنی بر Repository باعث میشوند که با تراکنشهای ناموفق یا پاره ای (partially-executed) مواجه شویم که نهایتا به یکپارچگی و صحت دادهها صدمه میزند. لازم به ذکر نیست که خطایابی و رفع چنین مشکلاتی شدیدا زمان بر و دردسر ساز است
برای مطالعه بیشتر
ایجاد Repositories بر روی UnitOfWork
به الگوی Repository در لایه DAL خود نه بگویید!
پیاده سازی generic repository یک ضد الگو است
نگاهی به generic repositories
بدون معکوس سازی وابستگیها، طراحی چند لایه شما ایراد دارد
public class TestViewModel { private readonly ITestService _testService; public TestViewModel(ITestService testService) //تزریق وابستگی در سازنده کلاس { _testService = testService; }
نام تمام Viewهای برنامه به View ختم میشوند و نام ViewModelها به ViewModel. برای مثال TestViewModel و TestView معرف یک ViewModel و View متناظر خواهند بود.
ساختار کلاسهای لایه سرویس برنامه
namespace DI07.Services { public interface ITestService { string Test(); } } namespace DI07.Services { public class TestService: ITestService { public string Test() { return "برای آزمایش"; } } }
علامتگذاری ViewModelها
در ادامه یک اینترفیس خالی را به نام IViewModel مشاهده میکنید:
namespace DI07.Core { public interface IViewModel // از این اینترفیس خالی برای یافتن و علامتگذاری ویوو مدلها استفاده میکنیم { } }
برای نمونه کلاس TestViewModel برنامه، با پیاده سازی IViewModel، به نوعی نشانه گذاری نیز شده است:
using DI07.Services; using DI07.Core; namespace DI07.ViewModels { public class TestViewModel : IViewModel // علامتگذاری ویوو مدل { private readonly ITestService _testService; public TestViewModel(ITestService testService) //تزریق وابستگی در سازنده کلاس { _testService = testService; } public string Data { get { return _testService.Test(); } } } }
تنظیمات آغازین IoC Container مورد استفاده
در کلاس استاندارد App برنامه WPF خود، کار تنظیمات اولیه StructureMap را انجام خواهیم داد:
using System.Windows; using DI07.Core; using DI07.Services; using StructureMap; namespace DI07 { public partial class App { protected override void OnStartup(StartupEventArgs e) { base.OnStartup(e); ObjectFactory.Configure(cfg => { cfg.For<ITestService>().Use<TestService>(); cfg.Scan(scan => { scan.TheCallingAssembly(); // Add all types that implement IView into the container, // and name each specific type by the short type name. scan.AddAllTypesOf<IViewModel>().NameBy(type => type.Name); scan.WithDefaultConventions(); }); }); } } }
همچنین در ادامه از قابلیت اسکن این IoC Container برای یافتن کلاسهایی که IViewModel را در اسمبلی جاری پیاده سازی کردهاند، استفاده شده است. متد NameBy، سبب میشود که بتوان به این نوعهای یافت شده از طریق نام کلاسهای متناظر دسترسی یافت.
اتصال خودکار ViewModelها به Viewهای برنامه
using System.Windows.Controls; using StructureMap; namespace DI07.Core { /// <summary> /// Stitches together a view and its view-model /// </summary> public static class ViewModelFactory { public static void WireUp(this ContentControl control) { var viewName = control.GetType().Name; var viewModelName = string.Concat(viewName, "Model"); //قرار داد نامگذاری ما است control.Loaded += (s, e) => { control.DataContext = ObjectFactory.GetNamedInstance<IViewModel>(viewModelName); }; } } }
استفاده از کلاس ViewModelFactory
در ادامه کدهای TestView و پنجره اصلی برنامه را مشاهده میکنید:
<UserControl x:Class="DI07.Views.TestView" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" mc:Ignorable="d" d:DesignHeight="300" d:DesignWidth="300"> <Grid> <TextBlock Text="{Binding Data}" /> </Grid> </UserControl> <Window x:Class="DI07.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:Views="clr-namespace:DI07.Views" Title="MainWindow" Height="350" Width="525"> <Grid> <Views:TestView /> </Grid> </Window>
using DI07.Core; namespace DI07.Views { public partial class TestView { public TestView() { InitializeComponent(); this.WireUp(); //تزریق خودکار وابستگیها و یافتن ویوو مدل متناظر } } }
دریافت پروژه کامل این قسمت
DI07.zip