Top 3 Open Source ASP.NET Core based e-commerce web applications
nopCommerce
SimplCommerce
grandnode ( Powered By nopCommerce) :It’s an open source, free, cross-platform e-commerce software based on ASP.NET Core 2.2 and MongoDB — NoSQL database. You can run it on Linux, Windows, and MacOS easily. GrandNode also supports Docker, so you are able to install it just in seconds with Docker.
نظرات مطالب
سفارشی سازی Header و Footer در PdfReport
با سلام خدمت جناب نصیری، ببخشید شما فرمودید
میخواهیم در Header گزارش بجای Header پیش فرض PdfReport یکی از قالبهای PDF تهیه شده توسط Open Office را نمایش دهیم (و یا هر ساختار دیگری را).
ولی در مثالی که در اینجا زدید در قسمت Header یک جدول ایجاد کردید حال اگر من بخواهم واقعاً از فایلی که با استفاده از OpenOffice ایجاد کرده ام و با استفاده از این روش مقدار TextBoxهای اون رو پر کرده ام استفاده کنم باید چه تغییری ایجاد کنم. ممنونم
میخواهیم در Header گزارش بجای Header پیش فرض PdfReport یکی از قالبهای PDF تهیه شده توسط Open Office را نمایش دهیم (و یا هر ساختار دیگری را).
ولی در مثالی که در اینجا زدید در قسمت Header یک جدول ایجاد کردید حال اگر من بخواهم واقعاً از فایلی که با استفاده از OpenOffice ایجاد کرده ام و با استفاده از این روش مقدار TextBoxهای اون رو پر کرده ام استفاده کنم باید چه تغییری ایجاد کنم. ممنونم
- خارج از موضوع بحث نکنید.
- ساختار ابتدایی پروژههای Blazor Server را در مطلب «Blazor 5x - قسمت دوم - بررسی ساختار اولیهی پروژههای Blazor» بررسی کردیم که در آن AddServerSideBlazor و غیره بحث شدهاند که شامل موارد دیگری مانند مشخص سازی روش رندر کامپوننتها و ... سیمکشیهای دیگری هم هست برای اجرای بدون خطا:
<component type="typeof(App)" render-mode="ServerPrerendered" />
من تمام مباحثی رو که زحمت کشیدن و ارائه کردین همراه با مسائلی که داخل نظرات این مطالب ارائه شده بود را مطالعه و حتی تست کردم که البته یه سریاش رو قبلا خونده بودم؛ ولی بازم چند تا سوال برام مطرح شد که تو این مطالب یا نظراتش جوابی دریافت نکردم
1-چرا ما از namespace و class Library جداگانه استفاده میکنیم؛ در صورتی که میشه با پوشه بندی این کار انجام داد. از این رو میپرسم که ما به جز متدهای الحاقی و یه سری متدهای کمکی و همیشگی مثل ارسال ایمیل و مثلا تولید اعداد تصادفی و کپچا، اکثر متدهایی که استفاده میکنیم مربوط به همین پروژه است و در پروژههای دیگه کارایی نداره. پس منطقی هست که کلاسها و متدهایی که توی پروژههای دیگه میشه ازشون استفاده کرد رو به صورت یک class Library جداگانه تعریف کرد و بقیه پروژه داخل یک class Library. منطق جداکردن را متوجه نمیشم .
2- این نوع لایه بندی و تزریق وابستگی برای پروژههای کوچیک مثل یک سایت معرفی یک کسب و کار و شاید فروش چند تا محصول هم کارآیی داره یا به خاطر حجم کدنویسی بالا و حتی پیچیدگی در بعضی موارد که این بخش مال کدوم لایه است فقط برای پروژههای بزرگ و تصمیم بر توسعه بیشتر استفاده میشه.
1-چرا ما از namespace و class Library جداگانه استفاده میکنیم؛ در صورتی که میشه با پوشه بندی این کار انجام داد. از این رو میپرسم که ما به جز متدهای الحاقی و یه سری متدهای کمکی و همیشگی مثل ارسال ایمیل و مثلا تولید اعداد تصادفی و کپچا، اکثر متدهایی که استفاده میکنیم مربوط به همین پروژه است و در پروژههای دیگه کارایی نداره. پس منطقی هست که کلاسها و متدهایی که توی پروژههای دیگه میشه ازشون استفاده کرد رو به صورت یک class Library جداگانه تعریف کرد و بقیه پروژه داخل یک class Library. منطق جداکردن را متوجه نمیشم .
2- این نوع لایه بندی و تزریق وابستگی برای پروژههای کوچیک مثل یک سایت معرفی یک کسب و کار و شاید فروش چند تا محصول هم کارآیی داره یا به خاطر حجم کدنویسی بالا و حتی پیچیدگی در بعضی موارد که این بخش مال کدوم لایه است فقط برای پروژههای بزرگ و تصمیم بر توسعه بیشتر استفاده میشه.
از زمان Angular 2 به بعد، تنها یک نام برای نگارشهای جدید آن درنظر گرفته شدهاست و آن هم «Angular» است. بنابراین در اینجا منظور از Angular همان +AngularJS 2.0 است.
ایجاد و توزیع برنامههای جدید AngularJS به همراه تمام وابستگیهای آنها و همچنین رعایت بهترین تجربههای کاری آن، اندکی مشکل است. به همین جهت تیم Angular برنامهای را به نام Angular CLI تدارک دیدهاست که تمام این مراحل را به سادگی هرچه تمامتر مدیریت میکند. ممکن است قالبهای زیادی را در مورد شروع به کار با AngularJS 2.0+ در وب پیدا کنید؛ اما هیچکدام از آنها تمام قابلیتهای Angular CLI را ارائه نمیدهند و همواره چندین قدم عقبتر از تیم Angular هستند. به همین جهت در طی یک سری قصد داریم قابلیتهای گوناگون این ابزار را بررسی کنیم.
Angular CLI چیست؟
ایجاد برنامههای جدید Angular لذت بخش هستند؛ اما ایجاد برنامههایی که از بهترین تجربههای کاری توصیه شدهی توسط تیم Angular پیروی میکنند، به همراه Unit tests هستند و همچنین برای توزیع بهینه سازی شدهاند، بسیار چالش برانگیز میباشند. به همین جهت برنامهی خط فرمانی به نام Angular CLI برای مدیریت این مسایل توسط تیم Angular ایجاد شدهاست، تا توسعه دهندگان بیشتر وقت خود را صرف بهینه سازی کدهای خود کنند تا اینکه درگیر تدارک مسایل جانبی این فریم ورک باشند.
اگر به پروژههای سورس باز ارائه شدهی جهت شروع کار با +AngularJS 2.0 دقت کنید، تعداد بیشماری پروژهی seed، قالبهای آماده، کدساز و غیره را خواهید یافت. اکثر آنها تفاوتهای قابل ملاحظهای را با یکدیگر داشته و در اغلب موارد بهترین تجربههای کاری Angular را نیز رعایت نمیکنند. برای مثال خبری از style guide آن و یا مباحث بهینه سازی ساخت و توزیع لحاظ شدهی در نگارشهای جدید Angular، در آنها نیست.
در اینجا بود که تیم Angular تصمیم گرفت تا در جهت ساماندهی به این وضعیت آشفته، برنامهی Angular CLI را ایجاد کند تا برنامه نویسها به همراه ابزاری باشند که بر اساس بهترین تجربههای کاری Angular تهیه شدهاست؛ سبب ایجاد برنامههایی خواهد شد که یکدست به نظر میرسند و همچنین همواره آخرین تغییرات توزیع و آزمایش برنامهها را نیز به همراه دارد.
پیشنیازهای نصب Angular CLI
پیش از شروع به نصب Angular CLI باید مطمئن شوید که آخرین نگارش NodeJS را نصب کردهاید. برای این منظور خط فرمان را گشوده و دستور ذیل را صادر کنید:
در اینجا نگارش نصب شدهی بر روی سیستم من 5.10 است که برای کار با Angular CLI مناسب نیست و این برنامهی خط فرمان، حداقل نیاز به نصب نگارش 6.9 آنرا دارد. به همین جهت نیاز است به آدرس https://nodejs.org/en/download مراجعه کرده و آخرین نگارش node.js را دریافت و نصب کرد.
اگر این مطلب را در چند ماه بعد پس از نگارش آن مطالعه میکنید، به پروژهی Angular CLI مراجعه کرده و قسمت Prerequisites مستندات ابتدایی آنرا برای مشاهدهی آخرین نگارش NodeJS مورد نیاز آن، بررسی کنید.
نصب Angular CLI
پس از نصب پیشنیاز آن، اکنون خط فرمان را گشوده و دستور ذیل را صادر کنید:
به این ترتیب پس از چند دقیقه، Angular CLI به صورت global و عمومی نصب خواهد شد.
پس از نصب آن، جهت اطمینان از عملیات انجام شده، دستور ذیل را در خط فرمان صادر کنید:
کار سوئیچ list، ارائه گزارشی از بستههای عمومی نصب شدهی با نام angular/cli@ است. depth=0 به این معنا است که نیازی به تهیه لیستی از وابستگیهای آن نیست. برای نمونه خروجی آن میتواند به صورت ذیل باشد:
و همچنین برای مشاهدهی نگارش CLI نصب شده، دستور ذیل را اجرا نمائید:
در اینجا ng همان Angular CLI است.
ایجاد یک برنامهی جدید توسط Angular CLI
پس از نصب Angular CLI، اکنون میتوان از آن جهت ساخت یک برنامهی جدید Angular استفاده کرد. برای این منظور یک پوشهی جدید را ایجاد کرده و سپس از طریق خط فرمان به آن وارد شده (نگه داشتن دکمهی shift و سپس کلیک راست و انتخاب گزینهی Open command window here) و دستور ذیل را صادر کنید:
ng به معنای اجرای Angular CLI است. پارامتر new آن سبب ایجاد یک برنامهی جدید خواهد شد و پارامتر skip-install آن، کار فراخوانی خودکار npm install را لغو میکند. به این ترتیب میتوان در سریعترین زمان ممکن، یک برنامهی Angular را ایجاد کرد.
در اینجا ساختار یک پروژهی جدید Angular را مشاهده میکنید.
داخل پوشهی src، فایلهای اصلی پروژه قرار دارند:
- فایل main.ts نقطهی آغاز برنامه است.
با توجه به استفادهی از پارامتر skip-install، هنوز وابستگیهای فایل package.json نصب نشدهاند. برای این منظور به پوشهی اصلی پروژه وارد شده (جایی که پوشهی ngtest و فایل package.json قرار دارد) و دستور npm install را صادر کنید تا وابستگیهای برنامه نیز دریافت شوند. البته اگر از پارامتر یاد شده استفاده نمیشد، اینکار به صورت خودکار توسط ng new انجام میگرفت.
به این ترتیب وابستگیهای پروژه در پوشهی node_modules تشکیل خواهند شد.
به روز رسانی Angular CLI
روش به روز رسانی AngularCLI شامل این مراحل است:
الف) به روز رسانی بستهی عمومی نصب شدهی آن
ابتدا باید نگارش موجود عزل شود. سپس cache قدیمی مربوط به npm نیز باید پاک شود و پس از آن نیاز است مجددا آخرین نگارش cli نصب گردد.
ب) به روز رسانی یک برنامهی محلی
در ادامه به پوشهی برنامهی خود وارد شده و دستورات ذیل را اجرا کنید:
این دستورات ابتدا پوشههای node_modules و همچنین dist قبلی را پاک میکنند. دستور بعدی، کار به روز رسانی وابستگیهای package.json را انجام میدهد و در آخر دستور npm install، تغییرات فایل package.json را دریافت و نصب میکند.
مورد «الف» را به ازای هر نگارش جدید CLI، تنها یکبار باید انجام داد. اما مورد «ب» به ازای هر پروژهی موجود باید یکبار انجام شود (که سریعترین روش به روز رسانی وابستگیهای یک برنامه، به آخرین نگارش Angular است).
ایجاد و توزیع برنامههای جدید AngularJS به همراه تمام وابستگیهای آنها و همچنین رعایت بهترین تجربههای کاری آن، اندکی مشکل است. به همین جهت تیم Angular برنامهای را به نام Angular CLI تدارک دیدهاست که تمام این مراحل را به سادگی هرچه تمامتر مدیریت میکند. ممکن است قالبهای زیادی را در مورد شروع به کار با AngularJS 2.0+ در وب پیدا کنید؛ اما هیچکدام از آنها تمام قابلیتهای Angular CLI را ارائه نمیدهند و همواره چندین قدم عقبتر از تیم Angular هستند. به همین جهت در طی یک سری قصد داریم قابلیتهای گوناگون این ابزار را بررسی کنیم.
Angular CLI چیست؟
ایجاد برنامههای جدید Angular لذت بخش هستند؛ اما ایجاد برنامههایی که از بهترین تجربههای کاری توصیه شدهی توسط تیم Angular پیروی میکنند، به همراه Unit tests هستند و همچنین برای توزیع بهینه سازی شدهاند، بسیار چالش برانگیز میباشند. به همین جهت برنامهی خط فرمانی به نام Angular CLI برای مدیریت این مسایل توسط تیم Angular ایجاد شدهاست، تا توسعه دهندگان بیشتر وقت خود را صرف بهینه سازی کدهای خود کنند تا اینکه درگیر تدارک مسایل جانبی این فریم ورک باشند.
اگر به پروژههای سورس باز ارائه شدهی جهت شروع کار با +AngularJS 2.0 دقت کنید، تعداد بیشماری پروژهی seed، قالبهای آماده، کدساز و غیره را خواهید یافت. اکثر آنها تفاوتهای قابل ملاحظهای را با یکدیگر داشته و در اغلب موارد بهترین تجربههای کاری Angular را نیز رعایت نمیکنند. برای مثال خبری از style guide آن و یا مباحث بهینه سازی ساخت و توزیع لحاظ شدهی در نگارشهای جدید Angular، در آنها نیست.
در اینجا بود که تیم Angular تصمیم گرفت تا در جهت ساماندهی به این وضعیت آشفته، برنامهی Angular CLI را ایجاد کند تا برنامه نویسها به همراه ابزاری باشند که بر اساس بهترین تجربههای کاری Angular تهیه شدهاست؛ سبب ایجاد برنامههایی خواهد شد که یکدست به نظر میرسند و همچنین همواره آخرین تغییرات توزیع و آزمایش برنامهها را نیز به همراه دارد.
پیشنیازهای نصب Angular CLI
پیش از شروع به نصب Angular CLI باید مطمئن شوید که آخرین نگارش NodeJS را نصب کردهاید. برای این منظور خط فرمان را گشوده و دستور ذیل را صادر کنید:
C:\>node -v v5.10.1
اگر این مطلب را در چند ماه بعد پس از نگارش آن مطالعه میکنید، به پروژهی Angular CLI مراجعه کرده و قسمت Prerequisites مستندات ابتدایی آنرا برای مشاهدهی آخرین نگارش NodeJS مورد نیاز آن، بررسی کنید.
نصب Angular CLI
پس از نصب پیشنیاز آن، اکنون خط فرمان را گشوده و دستور ذیل را صادر کنید:
C:\>npm install -g @angular/cli
پس از نصب آن، جهت اطمینان از عملیات انجام شده، دستور ذیل را در خط فرمان صادر کنید:
C:\>npm list -g @angular/cli --depth=0
C:\>npm list -g @angular/cli --depth=0 C:\Users\Vahid\AppData\Roaming\npm `-- @angular/cli@1.0.0
و همچنین برای مشاهدهی نگارش CLI نصب شده، دستور ذیل را اجرا نمائید:
C:\>ng -v _ _ ____ _ ___ / \ _ __ __ _ _ _| | __ _ _ __ / ___| | |_ _| / △ \ | '_ \ / _` | | | | |/ _` | '__| | | | | | | / ___ \| | | | (_| | |_| | | (_| | | | |___| |___ | | /_/ \_\_| |_|\__, |\__,_|_|\__,_|_| \____|_____|___| |___/ @angular/cli: 1.0.0 node: 6.10.2 os: win32 x64
ایجاد یک برنامهی جدید توسط Angular CLI
پس از نصب Angular CLI، اکنون میتوان از آن جهت ساخت یک برنامهی جدید Angular استفاده کرد. برای این منظور یک پوشهی جدید را ایجاد کرده و سپس از طریق خط فرمان به آن وارد شده (نگه داشتن دکمهی shift و سپس کلیک راست و انتخاب گزینهی Open command window here) و دستور ذیل را صادر کنید:
> ng new ngtest --skip-install
در اینجا ساختار یک پروژهی جدید Angular را مشاهده میکنید.
فایل | توضیحات |
.angular-cli.json | تنظیمات cli را به همراه دارد. |
editorconfig | مربوط به تنظیمات VSCode است. |
karma.conf.js | برای انجام unit tests است. |
package.json | وابستگیهای npm برنامه را به همراه دارد (که در زمان نگارش این مطلب تنظیمات Angular 4 را به همراه دارد). |
protractor.conf.js | برای اجرای آزمونهای end to end که در اینجا e2e نام گرفتهاست، میباشد. |
tsconfig.json | تنظیمات کامپایلر TypeScript را به همراه دارد. |
tslint.json | جهت اجرای Lint و ارائهی بهترین تجربههای کاری با TypeScript است. |
داخل پوشهی src، فایلهای اصلی پروژه قرار دارند:
- فایل index.html کار ارائه و شروع برنامه را انجام میدهد.
- فایل main.ts نقطهی آغاز برنامه است.
با توجه به استفادهی از پارامتر skip-install، هنوز وابستگیهای فایل package.json نصب نشدهاند. برای این منظور به پوشهی اصلی پروژه وارد شده (جایی که پوشهی ngtest و فایل package.json قرار دارد) و دستور npm install را صادر کنید تا وابستگیهای برنامه نیز دریافت شوند. البته اگر از پارامتر یاد شده استفاده نمیشد، اینکار به صورت خودکار توسط ng new انجام میگرفت.
>npm install
به این ترتیب وابستگیهای پروژه در پوشهی node_modules تشکیل خواهند شد.
به روز رسانی Angular CLI
روش به روز رسانی AngularCLI شامل این مراحل است:
الف) به روز رسانی بستهی عمومی نصب شدهی آن
npm uninstall -g @angular/cli npm cache clean npm install -g @angular/cli@latest
ب) به روز رسانی یک برنامهی محلی
در ادامه به پوشهی برنامهی خود وارد شده و دستورات ذیل را اجرا کنید:
rm rmdir /S/Q node_modules dist npm install --save-dev @angular/cli@latest npm install
مورد «الف» را به ازای هر نگارش جدید CLI، تنها یکبار باید انجام داد. اما مورد «ب» به ازای هر پروژهی موجود باید یکبار انجام شود (که سریعترین روش به روز رسانی وابستگیهای یک برنامه، به آخرین نگارش Angular است).
در برنامههای مبتنی بر وب رایج، معمولا تبدیل تاریخ میلادی به شمسی در سمت سرور انجام میگیرد و تاریخ شمسی حاصل از تبدیل، به کاربر نمایش داده میشود. اما در برنامههای Single Page و یا به اختصار SPAها که کلاینت فقط با یک سری داده به فرمت JSON درگیر است، برای نمایش تاریخ شمسی به چه طریقی باید عمل کرد؟ آیا باید تاریخ را در سمت سرور به فرمت مورد نظر تبدیل کرد و یا در سمت کلاینت؟ همهی اینها از جمله سوالاتی هست که به هنگام توسعهی SPAها با آنها حتما درگیر خواهید شد.
شاید بتوان گفت که در SPA ها، هدف این است که از بار سرور تا حد ممکن کم کرد و آن را در بین کلاینتها توزیع کرد. در SPAها نقش اصلی سرور تامین داده هاست و بیشتر پردازشها در صورت امکان در سمت کلاینت انجام میشود و میبینید که حتی رندر کردن HTML نیز به عهدهی قالبهای سمت کلاینت است. البته هنوز هم میتوان قبل از اینکه داده را به فرمت JSON سریالایز کرد، سمت سرور بر روی آنها پیمایش انجام داده و تاریخهای میلادی را به شمسی تبدیل کرد که هدف ما این نیست و میخواهیم این کار را بر عهدهی مرورگر کاربر قرار دهیم.
معرفی moment.js
برای کار با دادههایی از جنس تاریخ در سمت کلاینت، کتابخانهی جاوا اسکریپتی قدرتمندی به نام moment.js وجود دارد. این کتابخانه دارای انواع و اقسام API برای نمایش و پردازش تاریخ هست. حتی میتواند relative time را نیز نمایش دهد. منظور از relative time این هست که به جای نمایش تاریخ، اختلاف آن را با زمان حال نمایش دهد. برای مثال مینویسند فلان پست در دو ساعت پیش ارسال شده و زمان دقیق ارسال پست را نمایش نمیدهد.
خوشبختانه برای افزودن تاریخ شمسی به این کتاب خانه، افزونهای به نام moment-jalaali برای آن تدارک دیده شده است. کار با آن نیز بسیار راحت است. کافی است در همان API هایی که برای فرمت کردن تاریخ در moment.js استفاده میکردید؛ یک j در ابتدای آنها قرار دهید که مثالهای کامل استفاده از آن را در مستندات آن میتوانید مشاهده کنید.
نحوهی استفاده از moment.js در AngularJS و ASP.NET
در ASP.NET فیلد هایی که از جنس DateTime هستند به شکل زیر به فرمت JSON سریالایز میشوند:
\/Date(1374222094520)\/
moment("/Date(1198908717056-0700)/"); // December 28 2007 10:11 PM
{{ name | uppercase }}
{{post.date | jalaliDate:'jYYYY/jMM/jDD hh:mm' }}
تعریف فیلتر jalaliDate نیز به شکل زیر است:
app.filter('jalaliDate', function () { return function (inputDate, format) { var date = moment(inputDate); return date.fromNow() + " " + date.format(format); } });
خروجی این فیلتر نیز به شکل "4 ماه پیش 1392/12/07 03:10" است و مشاهده میکنید که به کمک filterها در AngularJS انجام این گونه از کارها بسیار ساده و لذت بخش است.
توجه کنید که این فقط یک ایدهی ابتدایی و ساده از پیاده سازی فیلتر فوق است. قطعا با کمک APIهای متنوع momentjs و پارامترهای ورودی فیلتر، میتوان فیلتری بسیار پیشرفتهتر تعریف کرد.
دریافت کدهای یک مثال پیاده سازی شده با استفاده از کدهای فوق
نظرات اشتراکها
دوراهی انتخاب NHibernate و Entityframework
استفاده از NH در مقابل EF Code first سورس باز اشتباه است؛ به دلایل زیر:
- توهم پشتیبانی از بانکهای اطلاعاتی مختلف توسط NH . به شخصه با حداقل یک مورد نیم بند آن سروکار داشتم: SQL-CE. تقریبا بیشتر از نیمی از تواناییهای این بانک اطلاعاتی در NH لحاظ نشده و حتی یک کوئری ساده از تاریخ تا تاریخ را توسط آن نمیتوانید تهیه کنید. این مورد برعکس EF Code first است. کامل و بینقص کار میکند. کلا تمام محصولات مایکروسافت به همین نحو هستند. اگر عنوان میکنند این محصول دو قابلیت دارد، واقعا این دو قابلیت، درست کار میکنند. نه اینکه عنوان کنند 100 قابلیت را ارائه میدهیم و فقط 10 تای آن کامل پیاده سازی شده باشند.
- تیم مدیریتی به شدت مغرور و ناراحت NH. باز هم برای این تیم ناراحت، جهت تکمیل نقایص کار با SQL-CE بیشتر از یکسال قبل وصلهای رو ارسال کردم. تا به امروز حتی یک پاسخ که آیا خوبه، بده ... ارسال نشده. با اکثر همکاریها هم به همین نحو رفتار میکنند.
خلاصه حال و هوای یک پروژه سالم سورس باز را ندارد.
- پس از ارائه EF Code first این پروژه تقریبا غیرفعال شده: (^)
- نیم بند بودن پشتیبانی از LINQ. باز هم اگر تصور میکنید که راحت میتونید مثل EF از کوئریهای LINQ در اینجا استفاده کنید، سخت در اشتباه هستید.
- دیر به روز شدن کتابخانههای جانبی آن. این مساله هم به مدیریت بد پروژه NH بر میگردد. شاید بیشتر از 10 مورد افزونه برای NH هست، مانند کش و اعتبار سنجی و غیره. اما ... صاحبان آن مشخص نیستند! امروز NH3 ارائه میشود، سه ماه بعد کتابخانه اعتبارسنجی متناظر با آن. تیم NH هم حاضر نشده تمام اینها رو کنار هم قرار بده و یک کار یکپارچه رو ارائه کنه. NH اعتبار خودش رو از این افزونههای موجود در NH Contrib کسب میکنه، اما حاضر نیستند مدیریت و نگهداری یکپارچه آنها را قبول کنند.
- ناسازگاری با اکوسیستم دات نت. اگر از NH استفاده کنید مدام در حال جنگ با دات نت هستید. مثلا سیستم اعتبار سنجی EF با سیستم اعتبار سنجی سمت کلاینت و سرور MVC یکپارچه است. با NH اینطور نیست و از این نوع مثالها زیاد است. همین مساله حجم کاری شما را چندبرابر میکند.
- طراحی زمخت NH در مقابل طراحی روان EF. برای مثال در EF Code first شما به ندرت نیاز خواهید داشت که نگاشتها را تعریف یا حتی سفارشی سازی کنید. یک سری پیش فرض بسیار عالی در آن به صورت توکار (و نه به شکل افزونه) وجود دارد که حجم کاری شما را به شدت کاهش میدهند. در NH کتابخانه fluent nh سعی کرده که اینکار را انجام دهد اما جالب اینجا است که این کتابخانه از طرف تیم اصلی NH اصلا تحویل گرفته نشده و ... دست آخر هم یک روش دیگر را برای نوشتن نگاشتها با کد تهیه کردند.
- مستندات NH کامل نیست. برای مثال شاید یک سری بلاگهای متفرقه را پیدا کنید که در مورد روش تهیه نگاشتها با کد مطلب نوشته باشند ... نه توسط کسانی که این کتابخانه را تهیه کردهاند! این روند رو مقایسه کنید با وبلاگ EF مثلا : (^) این بلاگ تا این حد کامل است که مرجع بسیاری از مطالب آموزشی و کتابهای مرتبط با EF میباشد.
- سیستم migration موجود در EF Code first نسبت به نمونه NH بسیار کاملتر است؛ با قابلیت سفارشی سازی، مقایسه هش مدلها با جداول جهت جلوگیری از تداخلات و اشتباهات، تولید اسکریپت آپدیت بانک اطلاعاتی و غیره.
یک زمانی بود دات نت ORM قابل ملاحظهای نداشت. زمان دات نت2. در آن موقع NH حرف برای گفتن داشت اما ... نه الان.
- توهم پشتیبانی از بانکهای اطلاعاتی مختلف توسط NH . به شخصه با حداقل یک مورد نیم بند آن سروکار داشتم: SQL-CE. تقریبا بیشتر از نیمی از تواناییهای این بانک اطلاعاتی در NH لحاظ نشده و حتی یک کوئری ساده از تاریخ تا تاریخ را توسط آن نمیتوانید تهیه کنید. این مورد برعکس EF Code first است. کامل و بینقص کار میکند. کلا تمام محصولات مایکروسافت به همین نحو هستند. اگر عنوان میکنند این محصول دو قابلیت دارد، واقعا این دو قابلیت، درست کار میکنند. نه اینکه عنوان کنند 100 قابلیت را ارائه میدهیم و فقط 10 تای آن کامل پیاده سازی شده باشند.
- تیم مدیریتی به شدت مغرور و ناراحت NH. باز هم برای این تیم ناراحت، جهت تکمیل نقایص کار با SQL-CE بیشتر از یکسال قبل وصلهای رو ارسال کردم. تا به امروز حتی یک پاسخ که آیا خوبه، بده ... ارسال نشده. با اکثر همکاریها هم به همین نحو رفتار میکنند.
خلاصه حال و هوای یک پروژه سالم سورس باز را ندارد.
- پس از ارائه EF Code first این پروژه تقریبا غیرفعال شده: (^)
- نیم بند بودن پشتیبانی از LINQ. باز هم اگر تصور میکنید که راحت میتونید مثل EF از کوئریهای LINQ در اینجا استفاده کنید، سخت در اشتباه هستید.
- دیر به روز شدن کتابخانههای جانبی آن. این مساله هم به مدیریت بد پروژه NH بر میگردد. شاید بیشتر از 10 مورد افزونه برای NH هست، مانند کش و اعتبار سنجی و غیره. اما ... صاحبان آن مشخص نیستند! امروز NH3 ارائه میشود، سه ماه بعد کتابخانه اعتبارسنجی متناظر با آن. تیم NH هم حاضر نشده تمام اینها رو کنار هم قرار بده و یک کار یکپارچه رو ارائه کنه. NH اعتبار خودش رو از این افزونههای موجود در NH Contrib کسب میکنه، اما حاضر نیستند مدیریت و نگهداری یکپارچه آنها را قبول کنند.
- ناسازگاری با اکوسیستم دات نت. اگر از NH استفاده کنید مدام در حال جنگ با دات نت هستید. مثلا سیستم اعتبار سنجی EF با سیستم اعتبار سنجی سمت کلاینت و سرور MVC یکپارچه است. با NH اینطور نیست و از این نوع مثالها زیاد است. همین مساله حجم کاری شما را چندبرابر میکند.
- طراحی زمخت NH در مقابل طراحی روان EF. برای مثال در EF Code first شما به ندرت نیاز خواهید داشت که نگاشتها را تعریف یا حتی سفارشی سازی کنید. یک سری پیش فرض بسیار عالی در آن به صورت توکار (و نه به شکل افزونه) وجود دارد که حجم کاری شما را به شدت کاهش میدهند. در NH کتابخانه fluent nh سعی کرده که اینکار را انجام دهد اما جالب اینجا است که این کتابخانه از طرف تیم اصلی NH اصلا تحویل گرفته نشده و ... دست آخر هم یک روش دیگر را برای نوشتن نگاشتها با کد تهیه کردند.
- مستندات NH کامل نیست. برای مثال شاید یک سری بلاگهای متفرقه را پیدا کنید که در مورد روش تهیه نگاشتها با کد مطلب نوشته باشند ... نه توسط کسانی که این کتابخانه را تهیه کردهاند! این روند رو مقایسه کنید با وبلاگ EF مثلا : (^) این بلاگ تا این حد کامل است که مرجع بسیاری از مطالب آموزشی و کتابهای مرتبط با EF میباشد.
- سیستم migration موجود در EF Code first نسبت به نمونه NH بسیار کاملتر است؛ با قابلیت سفارشی سازی، مقایسه هش مدلها با جداول جهت جلوگیری از تداخلات و اشتباهات، تولید اسکریپت آپدیت بانک اطلاعاتی و غیره.
یک زمانی بود دات نت ORM قابل ملاحظهای نداشت. زمان دات نت2. در آن موقع NH حرف برای گفتن داشت اما ... نه الان.
مسیرراهها
Git
تصور عمومی در پروژههای سورس باز این است که چشمان باز بسیاری میتوانند جزئیات این نوع پروژهها را بررسی و رفع مشکل کنند. اما باگ Heartbleed در یک پروژهی بسیار معروف و پرکاربرد، از سال 2011 در مقابل چشمان بسیاری قرار داشته و در جهت یافتن یا رفع آن، اتفاق خاصی هم رخ نداده است ...
جزئیات فنی این باگ
جزئیات فنی این باگ