بازخوردهای دوره
تزریق وابستگی‌های AutoMapper در لایه سرویس برنامه
- محل تعریف نگاشت‌ها و کلاس‌های پروفایل، مهم نیست. چون اساسا هرجایی که قرار گیرند، دو وابستگی بیشتر نخواهند داشت: کلاس‌های مدل و کلاس‌های ViewModel.
- محل فراخوانی اولیه‌ی تعاریف نگاشت‌ها جهت معرفی آن‌ها به سیستم، مهم است.
+ اگر از کاربر اطلاعاتی را دریافت می‌کنید، در لایه UI هست که کار نگاشت اطلاعات دریافتی از کاربر و از ViewModelها به Modelهای اصلی برنامه انجام می‌شود (توسط متد Mapper.Map). اگر قرار است اطلاعاتی را بازگشت دهید، متدهای جدیدی مانند Project To بسیار بهینه‌تر هستند از روش قدیمی Mapper.Map و این متد را بهتر است در لایه سرویس استفاده کنید. متد Project To کارش بهینه سازی کوئری SQL ارسالی به سرور هست. اگر از روش Mapper.Map در لایه UI استفاده کنید، این قابلیت را از دست خواهید داد؛ چون Mapper.Map به معنای کار با اشیاء درون حافظه و LINQ to Objects است. کار متد ویژه‌ی Project To افزونه‌ای برای کار با Entity Framework و بهینه سازی آن است.
اشتراک‌ها
معرفی Mapster

 Writing mapping method is machine job. Do not waste your time, let Mapster do it.

Benchmark 

معرفی Mapster
نظرات مطالب
EF Code First #8
سلام. توی مدل‌های خود ارجاع دهنده، چجوری می‌شه Mapping رو طوری تنظیم کرد که در صورت پاک شدن یک عنصر، عناصر زیرمجموعه‌ی اون هم پاک بشن؟
نظرات مطالب
اجرای Stored Procedure با چند نوع مقدار برگشتی توسط EF CodeFirst
منظور من روش مشابه parameterAttribute‌ها در mapping  کردن ورودی‌های پروسیجرها در linq  می‌باشد.
نه اینکه صرفا از دستورات sql بصورت command استفاده شود.

مانند استفاده از پروسیجرها با چند ورودی و multiResult بودن آن در linq
  
مطالب
وی‍‍ژگی های پیشرفته ی AutoMapper - قسمت اول
در پست قبلی مقدمه‌ای داشتیم بر AutoMapper؛ مثالی که در اون پست عنوان شد ساده‌ترین و پرکاربردترین روش استفاده از AutoMapper هست بنام Flattening که در واقع از یک شیء کل به یک شیء کوچکتر می‌رسیم.
همانطور که در قسمت اول گفتم AutoMapper کارش رو بر اساس قراردادها انجام میده یا همون Convention Base. یکی از قردادهای AutoMapper، نگاشت براساس نام اعضای اون شی هست؛ مثلا در مثال قبلی FirstName در مبداء، به خاصیتی با همین نام نگاشت شد و ...

Projection
روش استفاده بعدی که به اون Projection (معنی فارسی خوب برا Projection چیه ؟) میگن برای مواقعی هست که اعضای یک شیء در مبداء، همتایی در مقصد ندارد (از نظر نام) و در واقع می‌خواهیم یک شیء رو به یک شیء دیگه تغییر شکل بدیم.
مدل زیر رو در نظر بگیرید:
  public class Person
    {
        public int Id { get; set; }

        public string FirstName { get; set; }       

        public string LastName { get; set; }

    }

  که قرار است به مدل PersonDTO نگاشت بشه.
  public class PersonDTO
    {
        public int Id { get; set; }

        public string Name { get; set; }

        public string Family { get; set; }

public string FullName { get; set; }

        public string Email { get; set; }
    }
همنطور که می‌بینید در مقصد خاصیت‌هایی داریم که در مبداء همتایی ندارند. برای نگاشت چنین اشیایی، از متد ForMember  استفاده و نگاشت‌های شی‌های موردنظر رو Custom می‌کنیم.
 Mapper.CreateMap<Person, PersonDTO>().ForMember(des => des.Name, op => op.MapFrom(src => src.FirstName)).
                ForMember(des => des.FullName, op => op.MapFrom(src => src.FirstName + " " + src.LastName)).ForMember(
                    des => des.Email, op => op.Ignore());
متد ForMember  از یک Action Delegate  برای کانفیگ کردن هر عضو استفاده میکنه. در مثال بالا ما از MapFrom برای اعمال نگاشت Custom  استفاده کردیم.
AutoMapper.IMappingExpression<TSource,TDestination>.ForMember(System.Linq.Expressions.Expression<System.Func<TDestination,object>>, System.Action<AutoMapper.IMemberConfigurationExpression<TSource>>)

نکته:برای تست کردن اینکه آیا نگاشت ما Exception  داره یا نه میتوان از متد زیر استفاده کرد.
Mapper.AssertConfigurationIsValid();

نکته
: همیشه موقع نگاشت، اعضای شیء مقصد برای AutoMapper  مهمن؛ مثلا در مثال بالا خاصیت LastName در مبداء به هیچ عضوی در مقصد نگاشت نشده (به صورت مستقیم) و این تولید Exception  نمیکنه ولی برعکس اون باعث تولید Exception میشه؛ مثلا اگه خاصیت Email  رو که در مبداء همتایی نداره رو کانفیگ نکنیم، باعث تولید Exception میشه.
 
نحوه استفاده
var person = new Person
                {
                    Id = 1,
                    FirstName = "Mohammad",
                    LastName = "Saheb",
                    
                };
var personDTO = Mapper.Map<Person, PersonDTO>(person);
خروجی به شکل زیر میشه


Collection
بعد از نوشتن کانفیگ نگاشت‌ها، بدون نیاز به تنظیمات خاصی میتونیم مجموعه ای از شی‌های مبداء رو به مقصد نگاشت کنیم. مجموعه‌های پشتیبانی شده به شرح زیرن.
IEnumerable, IEnumerable<T>, ICollection, ICollection<T>, IList, IList<T>, List<T>.
و البته آرایه ها.
مثال
var persons = new[]
                {
                    new Person { Id = 1, FirstName = "Mohammad", LastName = "Saheb" },
                    new Person { Id = 2, FirstName = "Babak", LastName = "Saheb" }
                };

var personDTOs = Mapper.Map<Person[], List<PersonDTO>>(persons);
خروجی به شکل زیر میشه

Nested Mappings
برای نگاشت کلاس‌های تو در تو از این روش استفاده می‌کنیم و ...
فرض کنید در کلاس Person خاصیتی از نوع Address داریم و در کلاس PersonDTO  خاصیتی از نوع AddressDTO.
public class Address
    {
        public string Ad1 { get; set; }
        public string Ad2 { get; set; }
    }


public class AddressDTO
    {
        public string Ad1 { get; set; }
        public string Ad2 { get; set; }
    }
برای نگاشت‌هایی از این دست باید تنظیمات نگاشت مربوط به نوع‌های تودرتو را صریحا معین کنیم.
Mapper.CreateMap<Address, AddressDTO>();
نکته: هرچند منطقی‌تر بنظر میرسه که تعریف نگاشت‌های داخلی ابتدا بیاد، ولی فرقی نمیکنه که تعریف این نگاشت قبل یا بعد از نگاشت اصلی باشه.
ادامه دارد...
مطالب
آشنایی با آزمایش واحد (unit testing) در دات نت، قسمت 5

ادامه آشنایی با NUnit

حالت‌های مختلف Assert :

NUnit framework حالت‌های مختلفی از دستور Assert را پشتیبانی می‌کند که در ادامه با آنها آشنا خواهیم شد.

کلاس Assertion :
این کلاس دارای متدهای زیر است:
public static void Assert(bool condition)
public static void Assert(string message, bool condition)

تنها در حالتی این بررسی موفقیت آمیز گزارش خواهد شد که condition مساوی true باشد
public static void AssertEquals(string message, object expected, object actual)
public static void AssertEquals(string message, float expected, float actual, float delta)
public static void AssertEquals(string message, double expected, double actual, double delta)
public static void AssertEquals(string message, int expected, int actual)
public static void AssertEquals(int expected, int actual)
public static void AssertEquals(object expected, object actual)
public static void AssertEquals(float expected, float actual, float delta)
public static void AssertEquals(double expected, double actual, double delta)

تنها در صورتی این بررسی به اثبات خواهد رسید که اشیاء actual و expected یکسان باشند. (دلتا در اینجا به عنوان تلرانس آزمایش درنظر گرفته می‌شود)

public static void AssertNotNull(string message, object anObject)
public static void AssertNotNull(object anObject)

این بررسی تنها در صورتی موفقیت آمیز گزارش می‌شود که شیء مورد نظر نال نباشد.

public static void AssertNull(string message, object anObject)
public static void AssertNull(object anObject)

این بررسی تنها در صورتی موفقیت آمیز گزارش می‌شود که شیء مورد نظر نال باشد.

public static void AssertSame(string message, object expected, object actual)
public static void AssertSame(object expected, object actual)

تنها در صورتی این بررسی به اثبات خواهد رسید که اشیاء actual و expected یکسان باشند.

public static void Fail(string message)
public static void Fail()

همواره Fail خواهد شد. (در مورد کاربرد آن در قسمت بعد توضیح داده خواهد شد)


نکته:
در یک متد آزمایش واحد شما مجازید به هرتعدادی که لازم است از متدهای Assertion استفاده نمائید. در این حالت اگر تنها یکی از متدهای assertion با شکست روبرو شود، کل متد آزمایش واحد شما مردود گزارش شده و همچنین عبارات بعدی Assertion بررسی نخواهند شد. بنابراین توصیه می‌شود به ازای هر متد آزمایش واحد، تنها از یک Assertion استفاده نمائید.

مهم!
کلاس Assertion منسوخ شده است و توصیه می‌شود بجای آن از کلاس Assert استفاده گردد.

آشنایی با کلاس Assert :
این کلاس از متدهای زیر تشکیل شده است:

الف) بررسی حالت‌های تساوی

Assert.AreEqual( object expected, object actual );

جهت بررسی تساوی دو شیء مورد بررسی و شیء مورد انتظار بکار می‌رود.

Assert.AreNotEqual( object expected, object actual );

جهت بررسی عدم تساوی دو شیء مورد بررسی و شیء مورد انتظار بکار می‌رود.
برای مشاهده انواع و اقسام overload های آن‌ها می‌توانید به راهنمای NUnit که پس از نصب، در پوشه doc آن قرار می‌گیرد مراجعه نمائید.

همچنین دو متد زیر و انواع overload های آن‌ها جهت برسی اختصاصی حالت تساوی دو شیء بکار می‌روند:

Assert.AreSame( object expected, object actual );
Assert.AreNotSame( object expected, object actual );

بعلاوه اگر نیاز بود بررسی کنیم که آیا شیء مورد نظر حاوی یک آرایه یا لیست بخصوصی است می‌توان از متد زیر و oveload های آن استفاده نمود:

Assert.Contains( object anObject, IList collection );

ب) بررسی حالت‌های شرطی:

Assert.IsTrue( bool condition );

تنها در حالتی این بررسی موفقیت آمیز گزارش خواهد شد که condition مساوی true باشد

Assert.IsFalse( bool condition);

تنها در حالتی این بررسی موفقیت آمیز گزارش خواهد شد که condition مساوی false باشد
Assert.IsNull( object anObject );

این بررسی تنها در صورتی موفقیت آمیز گزارش می‌شود که شیء مورد نظر نال باشد.
Assert.IsNotNull( object anObject );

این بررسی تنها در صورتی موفقیت آمیز گزارش می‌شود که شیء مورد نظر نال نباشد.

Assert.IsNaN( double aDouble );

این بررسی تنها در صورتی موفقیت آمیز گزارش می‌شود که شیء مورد نظر عددی نباشد (اگر با جاوا اسکریپت کار کرده باشید حتما با isNan آشنا هستید، is not a numeric ).

Assert.IsEmpty( string aString );
Assert.IsEmpty( ICollection collection );

جهت بررسی خالی بودن یک رشته یا لیست بکار می‌رود.

Assert.IsNotEmpty( string aString );
Assert.IsNotEmpty( ICollection collection );

جهت بررسی خالی نبودن یک رشته یا لیست بکار می‌رود.

ج) بررسی حالت‌های مقایسه‌ای

Assert.Greater( double arg1, double arg2 );
Assert.GreaterOrEqual( int arg1, int arg2 );
Assert.Less( int arg1, int arg2 );
Assert.LessOrEqual( int arg1, int arg2 );

نکته‌ای را که در اینجا باید در نظر داشت این است که همواره شیء اول با شیء دوم مقایسه می‌شود. مثلا در حالت اول، اگر شیء اول بزرگتر از شیء دوم بود، آزمایش مورد نظر با موفقیت گزارش خواهد شد.
از ذکر انواع و اقسام overload های این توابع جهت طولانی نشدن مطلب پرهیز شد.

د) بررسی نوع اشیاء

Assert.IsInstanceOfType( Type expected, object actual );
Assert.IsNotInstanceOfType( Type expected, object actual );
Assert.IsAssignableFrom( Type expected, object actual );
Assert.IsNotAssignableFrom( Type expected, object actual );

این توابع و Overload های آن‌ها امکان بررسی نوع شیء مورد نظر را میسر می‌سازند.

ه) متدهای کمکی
Assert.Fail();
Assert.Ignore();

در حالت استفاده از ignore ، آزمایش واحد شما در حین اجرا ندید گرفته خواهد شد. از متد fail برای طراحی یک متد assertion سفارشی می‌توان استفاده کرد. برای مثال:
طراحی متدی که بررسی کند آیا یک رشته مورد نظر حاوی عبارتی خاص می‌باشد یا خیر:

public void AssertStringContains( string expected, string actual,
string message )
{
if ( actual.IndexOf( expected ) < 0 )
Assert.Fail( message );
}

و) متدهای ویژه‌ی بررسی رشته‌ها

StringAssert.Contains( string expected, string actual );
StringAssert.StartsWith( string expected, string actual );
StringAssert.EndsWith( string expected, string actual );
StringAssert.AreEqualIgnoringCase( string expected, string actual );
StringAssert.IsMatch( string expected, string actual );

این متدها و انواع overload های آن‌ها جهت بررسی‌های ویژه رشته‌ها بکار می‌روند. برای مثال آیا رشته مورد نظر حاوی عبارتی خاص است؟ آیا با عبارتی خاص شروع می‌شود یا با عبارتی ویژه، پایان می‌پذیرد و امثال آن.

ز) بررسی فایل‌ها

FileAssert.AreEqual( Stream expected, Stream actual );
FileAssert.AreEqual( FileInfo expected, FileInfo actual );
FileAssert.AreEqual( string expected, string actual );

FileAssert.AreNotEqual( Stream expected, Stream actual );
FileAssert.AreNotEqual( FileInfo expected, FileInfo actual );
FileAssert.AreNotEqual( string expected, string actual );

این متدها جهت مقایسه دو فایل بکار می‌روند و ورودی‌های آن‌ها می‌تواند از نوع stream ، شیء FileInfo و یا مسیر فایل‌ها باشد.

ح) بررسی collections

CollectionAssert.AllItemsAreInstancesOfType( IEnumerable collection, Type expectedType );
CollectionAssert.AllItemsAreNotNull( IEnumerable collection );
CollectionAssert.AllItemsAreUnique( IEnumerable collection );
CollectionAssert.AreEqual( IEnumerable expected, IEnumerable actual );
CollectionAssert.AreEquivalent( IEnumerable expected, IEnumerable actual);
CollectionAssert.AreNotEqual( IEnumerable expected, IEnumerable actual );
CollectionAssert.AreNotEquivalent( IEnumerable expected,IEnumerable actual );
CollectionAssert.Contains( IEnumerable expected, object actual );
CollectionAssert.DoesNotContain( IEnumerable expected, object actual );
CollectionAssert.IsSubsetOf( IEnumerable subset, IEnumerable superset );
CollectionAssert.IsNotSubsetOf( IEnumerable subset, IEnumerable superset);
CollectionAssert.IsEmpty( IEnumerable collection );
CollectionAssert.IsNotEmpty( IEnumerable collection );

به صورت اختصاصی و ویژه نیز می‌توان بررسی مقایسه‌ای را بر روی اشیایی از نوع IEnumerable انجام داد. برای مثال آیا معادل هستند، آیا شیء مورد نظر نال نیست و امثال آن.

نکته: در تمامی overload های این توابع، آرگومان message نیز وجود دارد. از این آرگومان زمانیکه آزمایش با شکست مواجه شد، جهت ارائه اطلاعات بیشتری استفاده می‌گردد.

ادامه دارد...