در حالاتی که از AutoMapper در یک عبارت LINQ استفاده بشه در صورت وجود مواردی همچون FullName در مقصد خطای "Object reference not set to an instance of an object" رو throw می‌کنه.

آیا شما هم با چنین مشکلی برخورد کردید؟

مقاله خیلی کامل و جامعی بود.

بسیار سود بردم.

یک سوال

اگر من به دلایلی لازم باشه از جند DbContext استفاده کنم (فرض کنید یکی برای اطلاعات اصلی و یکی برای فایل‌ها و ...) در این حالت به چه شکلی می‌توان از این الگو استفاده کرد؟

آیا لازم است که چند نوع UOW ایجاد شود؟

یک سوال.

در لایه سرویس اگر یک عملیات مشترک باشد (به عنوان مثال درهم سازی (Hash) کلمه عبور کاربر) به نظر شما بهتر است در کجا قرار گیرد.

1) به عنوان مثال اگر در Ef.....Service قرار گیرد خیلی جالب، زیبا و مربوط نیست.

2) میشه در یک بخش دیگر (مثلا مشترک) قرار گیره، که خوب بازم مسئله اینه که این متد همیشه به بخش کاربران سرویس میده و عملا نباید جدا باشه.

3) میشه از یک کلاس میانی انتزاعی استفاده کرد و متدهای مشترک در تمام انواع سرویس (EF، Fake، و یا ....) در دسترس باشه.

ممنون میشم که راهنمایی کنید.

در ضمن میشه توی سازنده استاتیک کلاس هم این موارد رو قرار داد تا فورا بعد از شروع برنامه همه کارها انجام شود.

در ضمن الان شما برای جلوگیری از خیلی مسائل مجبور شدید یک  Handler جهت پراکسی اطلاعات (چه ارسالی و چه دریافتی) ایجاد کنید که از خیلی لحاظ مشابه ذخیره فایل‌ها در پایگاه داده باشه.

در ضمن مگه اندازه فایل‌های ارسالی و ... چقدر است که نیازمند مقدار زیادی پردازش باشه. استفاده از مکانیزم‌های Cache موجود در asp.net هم می‌تونه کمک کنه.

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

همچنین پشتیبان گیری را راحت می‌کند.

به نظر من  ایجاد اشیایی همانند Function و Stored Proc با وجود ORMهای امروزی، تا حدودی مناسب نیست (خارج از مواردی که مسائل Performance مطرح است).

ایجاد و بازسازی این اشیا در صورت وجود در هنگام Seed پایگاه داده (چه ایجاد و  چه تغییر) می‌تواند بسیاری از مشکلات موجود را حل کند.

به نظر من یک کار دیگه. استفاده از WITH SCHEMABINDING در زمان ایجاد اشیای وابسته است.