در مهندسی نرمافزار، شناخت دقیق نیازمندیها و سپس ساخت محصولی مطابق نیازمندیها یکی از کارهای به ظاهر ساده ولی در عمل پیچیده است. مطلب زیر داستانی را تشریح میکند که در آن یک مهندس نرمافزار هنگام خلقت زمین پروژه طراحی «زنبور» را بر عهده گرفتهاست. ولی به دلایلی که در داستان توضیح داده شده اقدام به طراحی یک «وزغ» میکند که هیچ تناسبی با نیازمندیهای «زنبور» ندارد. اگر لینک زیر را کامل بخوانید ارتباط آن را با پروژههای نرمافزاری میبینید و خواهید دید که چگونه این خطا باعث شکست یک پروژه نرمافزاری میشود.
در مورد ادامه ...
موضوع و مطلب، برای نوشتن بسیار زیاد هستند؛ اما این خوانندههای یک وبلاگ و یا یک وب سایت هستند که میتوانند نقش مهمی را در جهت گیری انتشار مطالب آن ایفاء کنند. به همین جهت ... به چه نوع مطالبی بیشتر علاقمندید، یا بیشتر مایلید که چه نوع مباحثی، در این سایت یا سایتهای مشابه مطرح شوند؟
خلاصه اشتراکهای روز پنج شنبه 3 آذر 1390
از طرفی به نظر من برای یه برنامه تجاری سازمانی، کاری که سیلورلایت انجام میده رو html نمی تونه به سادگی و راحتی انجام بده.
ASP.NET Web API - قسمت اول
یک تجربه
سالها پیش یکی از همکاران تعریف میکردند که یک شرکت نرم افزاری برای مشاوره معماری نرم افزار از ایشان دعوت به همکاری کرده است. پس از مراجعه به شرکت متوجه شدند که تیم اصلی برنامه نویسان درگیر تولید ORM ای برای پروژه جدید شرکت هستند که برای تولید این ابزار بیش از 4 ماه را وقت صرف کردهاند؛ اما در مراحل نهایی کار دچار مشکلات زیادی شده اند. به نحوی که از ایشان برای کمک به رفع مشکل ORM ( به جای تولید نرم افزار مشتری) دعوت کردهاند.
در آن زمان یادم هست که EF 5 (که تقریبا نسخه سوم بعد از 3.5 و 4 میباشد - جزئیات در اینجا) توسط مایکروسافت ارائه شده بود. همچنین NHibernate هم همزمان با EFها (تاریخچه نسخهها در اینجا) قابل دسترسی بودهاست. با این حال تیم فنی به این دلیل که کوئریهای تولیدی توسط EF کند هستند، اقدام به ساخت ORM کرده بودند. جالب اینکه با بررسی بیشتر مشخص شدهاست که حجم دادههای پروژه در بدترین حالت در یک جدول به 5 هزار رکورد میرسد.
4 ماه صرف وقت و هزینه تیم 2 نفره برای طراحی و پیاده سازی و تست ORM ای که در نهایت به دلیل مشکلات Performance کنار گذاشته شد و از EF استفاده کردند. شاید در این 4 ماه میتوانستند 30 درصد پروژه اصلی را پیاده سازی کنند.
شاید بتوان 3 دلیل عمده «فنی» شکست برخی از پروژههای نرم افزاری در ایران را به شرح زیر عنوان کرد:
- عدم استفاده مناسب از ابزارها و راهکارهای موجود و انجام دوباره کاری
- استفاده غیر ضروری و عجولانه از تکنولوژیهای جدید (بدون داشتن نیروی کار مسلط)
- پایین بودن سطح فنی و بهروز نبودن برخی از برنامه نویسان ایرانی
متن باز (Open Source)
با پیشرفت توسعه نرم افزار و تمایل شرکتهای بزرگ دنیا به تولید کامپوننتهای متن باز (Open Source) ریسک استفاده از این نوع ابزارها نیز کمتر شده است. بطوریکه درصورت نیاز میتوان کامپوننت را برای پروژهها سفارش سازی کرد.
شاید کمتر کسی باور میکرد که روزی شرکت مایکروسافت محصولات خود را Open Source کند. اما امروز، در سال 2017 میلادی، شرکت مایکروسافت اقدامات مهمی را در این زمینه انجام داده است که میتوانید جزئیات پروژههای متن باز این غول کامپیوتری دنیا را در اینجا و همچنین اینجا ملاحظه کنید.
یک سناریو
فرض کنید یک پروژه تحت وب را شروع کرده اید. بدون در نظر گرفتن جزئیات پروژه میتوان گفت به ابزارهای زیر نیاز خواهید داشت:
ابزار | مثال |
ORM | EF , NHibernate , Dapper , LLBLGEN |
IOC COntainer | Unity , StructureMap , Autofac , Castle.Windsor, LightInject , Ninject |
Report Tools | CrsytalReport , Stimusoft , DevExpress Report, Telerik Report Tools, EasyReport |
UI Component | Telerik , JqueryUI , Bootsrap ,CompnentArt, ComponentOne |
Error Logger | ELMAH , NLog , log4net |
Mapper Tools | AutoMapper , ValueInjecter |
ملاحظات استفاده از ابزارها
توجه به چند نکته در استفاده از ابزارها و کتابخانههای آماده ضروری میباشد، بدین شرح:
- ابزار مورد نیاز را با R&D (تحقیق و توسعه) انتخاب کنید. ابزارهایی که در پروژههای واقعی استفاده شدهاند، بسیار مناسب میباشند.
- توجه داشته باشیدکه استفاده از چندین ابزار باعث ایجاد تداخل در پروژه نشود (این مورد معمولا در کامپوننتهای UI مانند JqueryUI و Bootsrtap اتفاق میافتد)
- مستندات مربوط به ابزارها را حتما مطالعه کنید. لطفا بدون تسلط از ابزاری استفاده نکنید.
گاهی پیش میآید که یک برنامه نویس بدون مطالعه مستندات مربوط به یک IOC Container از آن ابزار استفاده میکند و در Register اولیه ویژگی LifeCycle مربوط به Context را با حالت Singleton مقداردهی میکند. بدین ترتیب پس از نیم ساعت، پروژه به دلیل آنچه که میتوان "چاقی Context" نامید، DONE یا حداقل کند میشود که رفع این مشکل ساعتها زمان میبرد.
درصورت امکان از ابزارها بصورت مستقیم استفاده نکنید. یک لایه واسط مخصوص خودتان را برای تنظیمات کلی ابزارها تهیه کنید که در آینده به دردتان خواهد خورد! (بیشتر در سمت سرور)
فرض کنید در پروژه WPF از کامپوننتهای زیبای DevExpress استفاده میکنید. به ازای هر کامپوننت یک کلاس به پروژه اضافه کنید که از کلاس اصلی آن کامپوننت Devexspress ارث میبرد و در لایه UI خود از کلاس جدید خود استفاده کنید. با این کار میتوانید ویژگیهای عمومی کامپوننتها را یکبار برای کل پروژه اعمال کنید.
نتیجه گیری
اگر بخواهیم چرخ را اختراع نکنیم و از تجربیات موفق موجود استفاده کنیم، میتوان نتیجه گرفت که استفاده از ابزارهای آماده برای توسعه نرم افزار با رعایت دستورالعمل استفاده امری مفید میباشد. اما باید توجه داشته باشیم که استفاده از هر ابزاری به هرقیمتی در هرپروژهای، حرفه ای نیست. همهی راهکارها، ابزراها و تکنولوژیهای مورد استفاده باید در راستای هدف اصلی «تولید و تحویل به موقع نرم افزار با کیفیت به مشتری» باشد؛ هدفی که در بسیاری از موارد فراموش شده و بیشتر زمان پروژه، صرف کارهای غیر ضروری میشود.
در این مقاله قصد داریم اطلاعات مفیدی را در مورد طراحی دیتابیسهای چند زبانه، در اختیار شما بگذاریم. مدتی قبل به طراحی دیتابیسی که چند زبانه بودن توضیحات کالا را برای مشتریانی از کشورهای مختلف پشتیبانی میکرد، نیاز داشتم. وقتی شروع به پیاده سازی طرح دیتابیس کردم، جواب سرراست نبود. زمانیکه در وب برای بهترین راه جستجو میکردم، با نظرات و روشهای زیادی مواجه شدم. در ادامه بعضی از روشهای محبوب را بیان میکنم.
ستون اضافی : این سادهترین راه است و به ازای هر ستونی که نیاز به ترجمه داشته باشد، ستون اضافی در نظر میگیریم.CREATE TABLE app_product ( Id Int IDENTITY NOT NULL, Description_en Text, Description_pl Text, PRIMARY KEY (Id) );
مزایا :
- سادگی
- کوئریهای آسان (بدون نیاز به join )
معایب :
- اضافه کردن زبان جدید نیاز به تغییر جداولی
که چند زبانه هستند دارد
- اگر وارد کردن داده برای همه زبانها الزامی
نباشد (بعضی جاها فقط زبان پیش فرض الزامی است) ممکن است دادههای زیاد و یا فیلدهای خالی در دیتابیس ایجاد شود
- نگهداری آن مشکل است
CREATE TABLE ref_language ( Code Char(2)NOT NULL, Name Varchar(20) NOT NULL, PRIMARY KEY (Code) ); CREATE TABLE app_translation ( Id Int IDENTITY NOT NULL, PRIMARY KEY (Id) ); CREATE TABLE app_translation_entry ( TranslationId Int NOT NULL, LanguageCode Char(2) NOT NULL, Text Text NOT NULL, FOREIGN KEY (TranslationId) REFERENCES app_translation(Id), FOREIGN KEY (LanguageCode) REFERENCES ref_language(Code) ); CREATE TABLE app_product ( Id Int IDENTITY NOT NULL, Description Int NOT NULL, PRIMARY KEY (Id), FOREIGN KEY (Description) REFERENCES app_translation(Id) );
مزایا :
- اضافه کردن زبان جدید به تغییر طرح دیتابیس
نیاز ندارد
- به نظر تمیز است و رویکرد رابطهای دارد
- همه ترجمهها در یک مکان است (بعضیها میگویند این جز معایب است چون امکان خوانایی و نگهداری کمتر است)
معایب :
- کوئریهای پیچیده (به join های چندگانه نیاز دارد تا شرح کالا را به درستی نمایش دهد)
- پیچیدگی زیاد
CREATE TABLE ref_language ( Code Char(2)NOT NULL, Name Varchar(20) NOT NULL, PRIMARY KEY (Code) ); CREATE TABLE app_product ( Id Int IDENTITY NOT NULL, PRIMARY KEY (Id) ); CREATE TABLE app_product_translation ( ProductId Int NOT NULL, LanguageCode Char(2) NOT NULL, Description Text NOT NULL, FOREIGN KEY (ProductId) REFERENCES app_product(Id), FOREIGN KEY (LanguageCode) REFERENCES ref_language(Code) );
مزایا :
- اضافه کردن زبان جدید به تغییر طرح دیتابیس
نیاز ندارد
- کوئریهای نسبتا ساده است
معایب :
- ممکن است تعداد جداول دو برابر شود
سه مثال نشان داده شده در بالا به ما ایده میدهند که چگونه روشهای مختلف ممکن است استفاده شوند. البته اینها همه گزینههای ممکن نیستند، فقط محبوبترین روشها هستند و شما میتوانید آنها را ویرایش کنید؛ به عنوان مثال با تعریف View های اضافی که join های پیچیده شما را در کدها، ذخیره میکنند. راه حلی که شما انتخاب میکنید به نیازمندیهای پروژه وابسته است. اگر شما به سادگی نیاز دارید و مطمئن هستید تعداد زبانهای پیشتیبانی کم و ثابت است، میتوانید راه حل اول را انتخاب کنید. اگر به انعطاف پذیری بیشتری نیاز دارید، میتوانید join های ساده در کوئریهای چند زبانه را انتخاب کنید. راه حل سوم انتخاب مناسبی است.
منبع :
http://fczaja.blogspot.com/2010/08/multilanguage-database-design.html
دریافت خروجی سایت
این خروجی هم صرفا برای کاربران فعال سایت درنظر گرفته شده است. کاربری در این سایت فعال نامیده میشود که حداقل یک مطلب جدید یا حداقل یک اشتراک جدید را ارسال کرده باشد.
پ.ن.
لطفا سعی نکنید برای رسیدن به این حد نصاب هر مطلب پیش پا افتاده یا هر لینک به سایتهای آشپزی که مطالب به نظر علمی را هم منتشر میکنند، ارسال کنید چون منجر به حذف اکانت شما خواهد شد.