تولید کد DB با Service Builder

بازدید : 418

اگر برنامه نویس باتجربه ای هستید احتمالاً قبلاً با اپلیکیشن data-driven روبه رو شده اید. لایفری ابزاری به نام Service Builder دارد که ایجاد اپلیکیشن های data-driven را آسان می کند. من شدیداً پیشنهاد می کنم که در زمان نوشتن اپلیکیشن ها روی پلتفرم لایفری از Service Builder استفاده کنید چون به شما کمک می کند که سریعتر پیش بروید. چگونه؟ با تولید دیتابیس زیاد کدها را برایتان درک می کند بنابراین می توانید روی قابلیت اپلیکیشنتان تمرکز کنید.

ابتدا به نیازی که Service Builder به آن پاسخ می دهد نگاهی می اندازیم. سپس خواهید دید که چگونه Service Builder را پیکربندی و اجرا نمایید تا لایه کد را ایجاد کنید که تراکنش دیتابیس را مدیریت کنید.

پرکردن یک نیاز مشخص

در گذشته ما عادت داشتیم کد JDBC خودمان را با ایجاد ارتباط با دیتابیس و اجرای روش هایی که SQL در آنها جاسازی شده بود roll. مطمئناً این روش پر از مشکل بود. نگهداری کد سخت بود چون برنامه نویس ها مجبور بودند تا توضیحات SQL از قبل تعریف شده را با قابلیت های اپلیکیشن که مرتباً در حال تغییر بود ترسیم نمایند. مشکل دیگر این بود که اپلیکیشن ها به طور محکم با لایه دیتابیس همراه می شدند و چالش هایی را در برابر قابل حمل بودن، ثبات و نگهداشت پذیری اپلیکیشن ها را نمایان می کردند. اپلیکیشن ها به حملات تزریقی SQL حساس می شدند. برنامه نویس ها مجبور بودند درباره باز کردن و بستن اتصالات به طور دستی نگران باشند، تراکنش ها را به طور دستی مدیریت کنند و گروهی از دیگر چیزها. انجام خوب این کار نیاز به دانش زیادی درباره هم دیتابیس ها و هم تمرینات برنامه نویسی خوب داشت.

بعد هر فردی ظرف مدیریت شده Enterprise Java Beans (EJBs) را آزمود. با استفاده از اینها برنامه نویسان به ظرف EJB اعتماد می کنند تا مخازن ارتباطی را مدیریت کنند، به طور پویا پارامترها را وارد کنند و غیره. اغلب عرضه کنندگان اپلیکیشن سرور ابزاری برای تولید اینها به طور اتوماتیک فراهم می کردند از جمله query هایی که اپلیکیشن ها احتیاج داشتند. مشکل این بو.د که استفاده از این ابزار ها اپلیکیشن ها را به اپلیکیشن سرورخاصی و دیتابیس خاصی گره می زد که بر خلاف آن EJB ها را تولید کرده اید. همچنین ابزارهایی که برای تولید کد استفاده می شد. علاوه بر این برنامه نویسان متوجه شدند که EJB ها برای نوشتن بسیار پیچیده بودند و در حافظه و پردازش توان هزینه سربار زیادی را به دوش می کشد. راه حل دیگری نیاز بود و دوباره آن راه حل متن باز برای نجات بود.

پروژه Hibernate روش متفاوتی را دنبال کرد. به منظور پیشنهاد یک API ساده به برنامه نویسان تا به دیتای یک دیتابیس دسترسی بیابند Hibernate کاری را انجام می دهد که به آن object/relational mapping (ORM) نامیده می شود. با استفاده از این نمونه جداول دیتابیس با موضوعات جاوا ترسیم می شوند (mapped). این برنامه نویسان را آزاد می گذارد تا با موضوعات جاوا که با آنها آشنا هستند کار کنند و Hibernate مراقب تداوم آن موضوعات روی دیتابیس است- هر دیتابیسی که Hibernate پشتیبانی می کند. کد دیتابیس شما بسیار آسانتر در چندین دیتابیس به کار می رود، به اپلیکیشن شما اجازه می دهد تا روی سیستم های متنوعتری اجرا شود. این به نوعی توضیح بسیار ساده شده Hibernate است- چون چیزهای بیشتری را در بر می گیرد- اما باید برای نیازهای شما کافی باشد. اگر می خواهید بیشتر درباره Hibernate  بیاموزید شدیداً پیشنهاد می کنم  Java Persistence with Hibernate (Manning 2006)را مطالعه کنید.

تکنولوژی دیگر که گاهی اوقات با Hibernate استفاده می شود اما برای چیزهای زیاد دیگری نیز مفید است Spring است. اگر درباره تزریق وابستگی (DI) شنیده باشید احتمالاً درباره Spring هم شنیده اید. و اگر درباره DI نشنیده اید روش کاملاً متفاوتی از فکر کردن درباره اینکه یک اپلیکیشن چگونه سازماندهی شده است. به طور مثال همه برنامه نویسان جاوا با این چیزها آشنا هستند:

MyObject something = new MyObject();

این یکی از اولین چیزهایی است که در یک کلاس جاوا یاد می گیرید: استفاده از یک سازنده برای ایجاد نمونه جدیدی از یک شئ. اگر کد جاوا می نویسید همیشه بدون فکر کردن درباره آن این کار را انجام می دهید. اما چه می شود اگر قبل از نوشتن چنین چیزی ابتدا این سوال را بپرسید: آیا این کلاس که روی آن کار میکنم به موضوع نمونه ای کاملی از این نوع بستگی دارد؟ به عبارت دیگر زمانی که نمونه این موضوع را ایجاد می کنید آیا باز مجبورید آن را یک دسته از مسائل که تا حالا داشته اید اشغال کنید؟ اگر چنین است DI را دوست خواهید داشت.

تعامل با دیتابیس به صورت دستی مستلزم این است که با یک دسته از اشیاء تردستی کنید که یکبار تنظیم کرده اید و سپس به دیگران بدهید تا آن را ببینند: Connection، DataSource ، DriverManager و غیره. هر گاه یک پرسش می پرسید نیاز دارید که این اشیاء را به دیگران بدهید تا ببینید (که بعضی از آنها دیگری را پنهان می کنند تا چیزی از دیتابیس بگیرند. Hibernate به یک چنین چیزی احتیاج دارد اما اشیاء کمی متفاوت هستند. ( SessionFactory، Datasource، HibernateProperties و غیره). آیا اگر می توانستید همه این چیزها را یکباره تنظیم کنید و سپس نسخه های نمونه این اشیاء را به کلاس هایی که به آنها نیاز دارند تزریق کنند عالی بود؟ آیا اگر می توانستید به طور اتوماتیک موضوعات را با پارامترهای شناخته شده بیان کنید و سپس آن اشیاء را به دیگر اشیاء که به آنها نیاز دارید تزریق کنید عالی نبود؟ با Spring می توانید این کار را انجام دهید. DI اجازه می دهد اشیاء را تعیین کنید که به دیگر اشیاء بستگی دارند و spring می تواند مثال های آن اشیاء مورد نیاز را به طور اتوماتیک تزریق کند. همه آنچه که نیاز دارید تا انجام دهید پیکربندی یک فایل XML است که آن وابستگی ها را تعیین می کند. با استفاده از Spring به طور اتوماتیک می توانید یک Hibernate Session را به کد تزریق کنید که دیتابیس را مورد تحقیق قرار می دهد، شما را از اینکه مجبور باشید که یک مثال از session بگیرید برای هر بار که می خواهید از دیتابیس دیتا بخواهید نجات می دهد{رها می سازد}. ترکیب Spring و Hibernate همیشه استفاده می شود، چون کار برنامه نویسان را آسانتر می کند.

اما اجازه دهید یک گام فراتر برویم. چه می شود اگر یک جدول دیتابیس در یک فایل XML تعریف شود و از آن تعریف همه پیکربندی Hibernate ، همه پیکربندی Spring، روشهای یابنده، لایه مدل SQL تا جدول روی دیتابیس های رهبری شده ایجاد کند و همه لایه Data Access Objects (DAO) در یک حرکت نزولی تولید شود؟ این چیزی است که Service Builder به شما می دهد. شکل ۱٫۱ این را نشان می دهد.

این ابزار تولید کننده کد با تداوم عالی دیتابیس است که تعریف جدول حدید و دستکاری دیتا در انتخاب کردن، وارد کردن، به روزآوری و حذف عملیات را آسان می کند. از ترکیب تکنولوژی های استانداردی استفاده می کنند – Hibernate و Spring- تا این کار را انجام دهند. مهم است که اشاره کنم دوام دیتابیس داخلی لایفری با استفاده از این ابزار تولید می شود در نتیجه یک ابزار اثبات شده است که کد تولید می کند و برای اجراهای سازمانی مناسب است.

اگر شما هم مثل من هستید می دانم سریعاً چه چیزی به ذهنتان رسید وقتی که “تولید کننده کد” را گفتم. این بود “اوه نه تولید کنندگان  کد بد هستند.” و سپس شروع به توجیه حرفتان با اصوات زیاد، دقیق و بحث های عالی شدید.

66920

شکل ۱٫۱   Service Builder ابزاری است که بالای Hibernate و Spring می نشیند و به طور اتوماتیک هر دو پیکربندی را برایتان تولید می کند- همراه کد جاوا که لازم است تا موجودیت شما را در دیتابیس نگهدارد.

 

از Service Builder استفاده خواهید کرد تا جداول دیتابیس را تولید کنید که پیشتر برای پورتلت ثبت محصول اینک ول تعریف شده بود و سپس برای تداوم دیتابیس از آن استفاده خواهید کرد. برای شروع باید یک فایل XML ایجاد کنید که کلید تولید الباقی کد است.

نظرات :0 نظر

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد.