در تمام ORMها استفاده میشه. NHibernate هم نوع خاص خودش را دارد. در EF از کلاس‌های پروکسی به دو منظور Lazy loading و change tracking استفاده میشه. به همین جهت خواصی که در lazy loading مورد استفاده قرار می‌گیرند باید virtual تعریف شوند. به این ترتیب ORM مورد استفاده می‌تونه این خواص رو جهت کاربردهای خودش، به صورت پویا بازنویسی و override کنه. با تنظیم DbContext.Configuration.ProxyCreationEnabled=false ، دو کاربرد یاد شده از کار خواهند افتاد. اطلاعات بیشتر رو می‌تونید در بلاگ یکی از اعضای تیم EF بخونید.

- مشکل کلاس کانفیگ فوق در این است که از یک طرف InverseProperty تعریف کردید، از طرف دیگر در حالت تنظیمات Fluent، این مورد رعایت نشده. مثلا DriverAssistance باید به TransferencesForAssistance (مطابق InverseProperty تعریف شده) مرتبط می‌شد و الی آخر (الان همگی به یک مورد مرتبط شدن).
- در کل نیازی به کلاس کانفیگ فوق ندارید. حذفش کنید. EF می‌تونه روابط one-to-many رو بدون کانفیگ خاصی تشخیص بده. علت وجود قسمت هفتم، اعمال یک سری تنظیمات اضافه‌تر است نسبت به تنظیمات پیش فرض. مثلا اگر از نام‌های پیش فرض خرسند نیستید، اینجا می‌تونید توسط Fluent API خیلی از این موارد رو سفارشی سازی کنید و تغییر بدید. البته شرطش هم این است که از ICollection برای معرفی موارد one-to-many استفاده کنید (که اینکار در کلاس Driver انجام شده، همچنین یک سر دیگر آن به صورت virtual در کلاس مقابل وجود دارد. به علاوه مطلب نحوه تعریف صحیح کلیدهای خارجی را هم اضافه کنید تا طراحی بهتری داشته باشید).

آخرین نسخه‌ای که من دارم: redactor803.zip

- این یک کار سورس باز هست. مطابق نیاز خودتون تغییرش بدید و استفاده کنید. برای استفاده‌ای که من دارم تنظیمات آن کافی است.
- در کار من قسمت‌هایی که کوئری استرینگ دارند عمومی نیستند و نیاز به اعتبارسنجی دارند. به همین جهت تبدیل آن‌ها برای بحث SEO اهمیتی نخواهند داشت. خصوصا قسمت کوئری استرینگ آن‌ها نباید تغییری کند چون در رمزگشایی اطلاعات از آن استفاده می‌شود.

احتمالا دانلود منیجر شما طوری تنظیم شده که لینک‌های PDF را پیش از نمایش در مرورگر، ردیابی می‌کند.

- نیاز به نمایش دهنده PDF نوشته شده با سیلورلایت دارید. یک سری کار تجاری از تلریک و امثال آن (^، ^) برای اینکار هست.
- حجم فایل نهایی به اندازه کافی فشرده شده است. استفاده از تصاویر یا تعداد صفحات بالا، حجم را بیشتر خواهند کرد به همراه بالا بردن مدت زمان تولید فایل. همچنین یک سری پیوست/خروجی جانبی نیز به فایل اضافه می‌شوند، مانند خروجی اکسل، xml و csv. هر کدام از این‌ها را که مورد نیاز نیستند، در حین تهیه گزارش ذکر نکنید تا فایل نهایی حجم کمتری داشته باشد. بدیهی است تولید هر کدام نیز زمانی را به خود اختصاص خواهند داد.
- مثالی که موجود بود را تست کردم حدود 1 ثانیه بیشتر طول نکشید؛ نه 20 ثانیه.
روشی وجود دارد به نام warmup برای خیلی از کارهای دات نتی. در پشت صحنه سیستم، حین اجرای اولیه برنامه یک گزارش خالی را تولید کنید. به این صورت سیستم JIT دات نت مجبور خواهد شد سریعتر وارد عمل شود (نه در زمان نیاز). در دفعه بعد فراخوانی گزارشات، نتیجه کار بسیار سریع خواهد بود.

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

- shift+space یا نیم فاصله اینجا استفاده شده بود.
- راه بهتر: مثال DynamicCrosstab رو کمی تغییر دادم. به events.RowStarted آن دقت کنید. در این روال رخداد گردان می‌تونید در هر نوع گزارشی در PdfReport، برچسب‌های سطر هدر جدول تولیدی رو پیش از درج در فایل گزارش، کلا تغییر بدید: (^)
- اگر سؤالی در مورد PdfReport دارید لطفا در قسمت سؤال و جواب‌های آن مطرح کنید.

بله (با استفاده از یک سرویس WCF). مثال‌های آن‌را دریافت کنید. مراجعه کنید به پوشه SLPdf آن جهت مشاهده یک نمونه آماده.

- تشخیص وجود کوئری استرینگ در یک Url، حالت دیگری نمی‌تونه داشته باشه.
- ضمنا یک Url می‌تونه کوئری استرینگی با چندین name-value داشته باشه. ضرورتی به بررسی تمام موارد و کند کردن کار نیست که آیا مقدار دارند همگی یا خیر.