بازگرداندن تغییرات داخل بانک [بایگانی]

Mrs.Net

شنبه 03 آذر 1386, 20:03 عصر

من در یکی از فرمهام کاربر چند نوع اطلاعات ثبت یا ویرایش میکنه و نهایتا تایید یا انصراف میکنه. برای انصراف راههترین راه چیه که تمام اون رکوردهای اضافه شده پاک بشوند و رکوردهای ویرایش شده به حالت قبل برگردند؟

combo_ci

شنبه 03 آذر 1386, 20:34 عصر

چرا از transanction استفاده نمیکنی......sqlcommand هم خاصیت transnction داره ...وقتی فرم رو باز کردی یک transaction فعال کن اگر کاربر انصراف رو زد transaction رو به حالت commit در بیار

Mrs.Net

شنبه 03 آذر 1386, 22:33 عصر

دوتا سوال دارم ممنون میشم جواب بدید:
1. اگر بعد از چندتا تغییر که هنوز هم کمیت نشدند
یکدفعه سیستم خراب بشه و بسته بشه چه اطفاقی واسه اطلاعات میفته؟ آیا برگردونده میشند یا ثبت میشن؟

2. وقتی یک کانکشن ترازاکشن میدیم و اون کانکشنو ببندیم close چه اتفاقی میافته؟
آیا اگه دوباره باز کنیم هنوز همون تغییرات در رل بک وجوددارند؟

اَرژنگ

یک شنبه 04 آذر 1386, 04:09 صبح

من در یکی از فرمهام کاربر چند نوع اطلاعات ثبت یا ویرایش میکنه و نهایتا تایید یا انصراف میکنه. برای انصراف راههترین راه چیه که تمام اون رکوردهای اضافه شده پاک بشوند و رکوردهای ویرایش شده به حالت قبل برگردند؟
اگر از برنامه نویسی ۳ لایه استفاده میکنید تا موقعی که لایه بیزنش به لایه داتا دستور نده که رکوردها را در داتابیس ثبت و یا تغییر بده احتیاج به هیچ‌ کاره اضافه دیگری ندارید.
هر جا کاربر انصراف کنه فرم را میبندید و هیچ چی در داتابیس تغییر نمیکنه، اگر که کاربر یک دگمه سیو را بزنه تمام داتا ها را از لایه بیزینس به لایه داتا میفرستید.
یکی از فایده‌هایه برنامه نویسی ۳ لایه همین است.

Alireza Orumand

یک شنبه 04 آذر 1386, 08:38 صبح

سلام.

یکی از فایده‌هایه برنامه نویسی ۳ لایه همین است.
در اصول دیتابیس قاعده ای وجود داره که اطلاعات یا باید کامل وارد دیتابیس بشن یا اصلا نباید ثبت بشن. خاصیت roll back شدن اطلاعات comit نشده هم در راستای پیاده سازی همین مورد هست و کاری به خواص برنامه نویسی لایه ای نداره.
در کل چه شما transaction ایجاد کنید، چه ایجاد نکنید(در این صورت خود sql server این کار رو انجام میده) اگر اطلاعات comit نشده باشند حالا به هر دلیلی(انصراف کاربر یا مشکل کامپیوتر) این اطلاعات تا رسیدن به اولین نقطه ی comit شده roll back میشن.

Mrs.Net

یک شنبه 04 آذر 1386, 09:45 صبح

در این قسمت از برنامه ام حتما باید چند رکورد ثبت بشن تا در حالت شبکه مشکلی پیش نیاد (شماره تکراری ایجاد نشه) و برای همین رکوردها ثبت میشن.
ولی در کل میخوام کامل بدونم که تو طراحیم کاملا درست انجام بدم.
از برنامه نویسی سه لایه استفاده میکنم و میخوام بدونم اونجا از ترانزاکشن استفاده نمیشه؟

در کل چه شما transaction ایجاد کنید، چه ایجاد نکنید(در این صورت خود sql server این کار رو انجام میده) اگر اطلاعات comit نشده باشند حالا به هر دلیلی(انصراف کاربر یا مشکل کامپیوتر) این اطلاعات تا رسیدن به اولین نقطه ی comit شده roll back میشن. تو بانک اکسس هم همینطوره؟یعنی وقتی سیستم بعد از خاموش شدن بالا اومد خود بانک برمیگرده؟ یا اصلا هنوز کامل ثبت نشده

اَرژنگ

یک شنبه 04 آذر 1386, 10:31 صبح

سلام.

در اصول دیتابیس قاعده ای وجود داره که اطلاعات یا باید کامل وارد دیتابیس بشن یا اصلا نباید ثبت بشن. خاصیت roll back شدن اطلاعات comit نشده هم در راستای پیاده سازی همین مورد هست و کاری به خواص برنامه نویسی لایه ای نداره.
در کل چه شما transaction ایجاد کنید، چه ایجاد نکنید(در این صورت خود sql server این کار رو انجام میده) اگر اطلاعات comit نشده باشند حالا به هر دلیلی(انصراف کاربر یا مشکل کامپیوتر) این اطلاعات تا رسیدن به اولین نقطه ی comit شده roll back میشن.
بله این اصول وجود دارند و متعلق به داتا لایر هستند، اینکه کاربر نظرش را عوض کرد و متعلق به لایه بیزینس هستش.
استفاده از ترانزکشن برایه این مورد به نظر من کار درستی نمیاد، اگر شما کدی دارید که راحتی این روش را نشان میده لطفا بفرستید.

اَرژنگ

یک شنبه 04 آذر 1386, 10:33 صبح

ولی در کل میخوام کامل بدونم که تو طراحیم کاملا درست انجام بدم.
از برنامه نویسی یه لایه استفاده میکنم و میخوام بدونم اونجا از ترانزاکشن استفاده نمیشه؟

اگر از برنامه نویسی یه لایه استفاده میکنید بیخیال باشید، از حرفهایه طراحی و ترانکشن داشتن و یا نداشتن گذشته.

Mrs.Net

یک شنبه 04 آذر 1386, 10:42 صبح

اگر از برنامه نویسی یه لایه استفاده میکنید بیخیال باشید، از حرفهایه طراحی و ترانکشن داشتن و یا نداشتن گذشته. اشتباه تایپی بود (ی و س نزدیک هم بودند) به هر حال خودتون چندتا از سوالات من راجب سه لایه جواب دادین :خجالت:
تو سیستم سه لایه از Transaction استفاده نمیشه؟
بنظرم بعضی مواقع احتیاج هست تا شماره های یکتا داخل بانک ذخیره بشن ولی همون لحظه هم کاربر از ادامه منصرف بشه. در این حالت رکوردهای اضافه شده با ترانزاکشن راحت تر برمیگردند. درست میگم؟

Alireza Orumand

یک شنبه 04 آذر 1386, 13:20 عصر

سلام

استفاده از ترانزکشن برایه این مورد به نظر من کار درستی نمیاد،
آرژنگ جان قصد من کل کل کردن نبود. فقط جایی شما بحثی در مورد علمی بودن مطالب کرده بودید من فقط هدفم این بود که مسئله از نظر عملی بودن بیشتر توجیه داشته باشه.
در مورد نیازی به استفاده کردن از ترنزکشن بودن یا نبودن باید خدمت شما عرض کنم که استفاده از ترنزکشن یکی از راه های پیاده سازی اصول پایگاه داده (ACID) هست. که اگر بخواهیم پایگاه داده اصولی و منطقی داشته باشیم باید به این اصول پایبند باشیم.
مثلا اگر یه کاربر بره از حساب خودش به حساب دیگه پول بریزه وقتی کاربر عملیات رو تایید کنه که پول ارسال بشه حالا انجام کار از طرف کاربر تایید میشه و مراحل زیر طی میشه که اول پول از حساب کنونی کسر میشه و بعد پول به حساب دیگه وارد میشه. حالا اگر پول کم شد ولی به x دلیل مختلف پول به حساب جدید وارد نشد چه اتفاقی میوفته هیچی به خاطر اینکه پایبندی به اصول ثابت شده کار درستی به نظر نمیرسه پول کاربر به دیار باقی میره.

اگر شما کدی دارید که راحتی این روش را نشان میده لطفا بفرستید

برای اثبات درستی یا نادرستی بعضی کارها نیاز به کد نیست، فقط نیاز به این هست که به دانسته های خودمون رجوع کنیم و مطلب رو یه بار دیگه بخونیم بعد بدون ناراحتی راجع به مطلب فکر کنیم. حرف من این بود که این مطلب جزء اصول دیتابیس هست حالا اگر شما میگید اشتباه میگم دیگه ...

تو بانک اکسس هم همینطوره؟یعنی وقتی سیستم بعد از خاموش شدن بالا اومد خود بانک برمیگرده؟ یا اصلا هنوز کامل ثبت نشده

بحث transaction در اصل یه روش پیاده سازی اصول پایگاه داده در sql server هست نه اینکه خودش یکی از اصول باشه. در مورد اکسس هم نمیدونم شما بررسی کنید که این اصل تو اکسس چطوری پیاده سازی شده. یا اصلا پیاده سازی شده یا خیر و خود شما باید پیاده سازی کنید.

اَرژنگ

یک شنبه 04 آذر 1386, 16:27 عصر

برای اثبات درستی یا نادرستی بعضی کارها نیاز به کد نیست، فقط نیاز به این هست که به دانسته های خودمون رجوع کنیم و مطلب رو یه بار دیگه بخونیم بعد بدون ناراحتی راجع به مطلب فکر کنیم. حرف من این بود که این مطلب جزء اصول دیتابیس هست حالا اگر شما میگید اشتباه میگم دیگه ...

من نگفتم که شما اشتباه میگید، فقط اینکه ترانزکشن در آخرین قسمت لایه داتا استفاده میشه، اگرچه حالا قابلیت داتشن ترانزکشن برایه عملایت بر رویه ابجکتها هم وجود دارد (من ندیدم ولی شنیدم، اگر کسی مثالی دارد بفرسته).

اگر گفتم کد بفرستید این نبود که اشتباه میگید، این بود که شاید چیزی هست من نمیدونم و این کار انجام دادنش آسان است (البته برایه اینکه کاری آسان است دیلل درستیش نیست، ولی من همیشه دنبال یاد گرفتن تکنتکهایه جدید هستم).

از اینکه جوابم به حالت کلکل آمد، خدمتتان پوزش عرض میکنم.
بله داشتن ترانزکشن همیشه برایه عملیاتی که قراره همه با هم انجام بشند و یا همه با هم انجام نشند درست است، من خودم از ترانزکشن برایه SQLServer 2005 در قسمت داتا لایر استفاده کردم و ارزشش را هم میدونم.
ولی این روش استفاده از ترانزکشن که اگر کاربر فکرش را عوض کرد ، معمولا مربوط‌ به قسمت ایترفیس و بیزینس لایر هست، و برایه همین از استفاده از ترانزکشن برایه همین کار تعجب کردم.

اَرژنگ

یک شنبه 04 آذر 1386, 16:46 عصر

اشتباه تایپی بود (ی و س نزدیک هم بودند) به هر حال خودتون چندتا از سوالات من راجب سه لایه جواب دادین :خجالت:

بله، فکر کردم این یک پروژه دیگه است، و گاها بعضی پروژه هایه کوچیک که قرار است محدود بمانند یک لایه‌ای نوشته میشند (و همان یک لایه بودن برایشان کافی است). در چنین شرایطی مهم نیست که ۳ لایه‌ای کار بشه، ولی حالا که فکر میکنم میبینم که جوابم اشتباه بود و اگر از ترانزکشن استفاده بشه بهتر است.

تو سیستم سه لایه از Transaction استفاده نمیشه؟
بنظرم بعضی مواقع احتیاج هست تا شماره های یکتا داخل بانک ذخیره بشن ولی همون لحظه هم کاربر از ادامه منصرف بشه. در این حالت رکوردهای اضافه شده با ترانزاکشن راحت تر برمیگردند. درست میگم؟
چرا در سیسم ۳ لایه از ترانزکشن هم استفاده میشه ولی نه برایه اینکه اگر کاربر نظرش را عوض کرد، معمولا در لایه اینترفیس و بیزینس تمام مراحل تمام میشه و کاربر درخواست ثبت داتا را میده، در این حالت ابجکتهایه بیزینس از لایه اینترفیس به لایه بیزینس برگرداننده میشند (اگر کاربر منصرف بشه، چیزی لازم نیست به لایه بیزینس برگرده)و لایه بیزینس از لایه داتا درخواست دادن تغییرات را میکند، در این حال فقط ترانزکشن در لایه داتا استفاده میشه و منصرف شدن کاربر ربطی به استفاده از ترانزکشن نداره (فقط برایه انجام دادن تمام تغییرات در داتابیس باهم بکار میره.).
من فقط سعی میکنم که این را برسانم، تا موقعی که کاربر قبول نکرده که تغییرات انجام بشه به داتابیش تغییری وارد نشه (استفاده از لایه اینتفیس و بیزینس کافی است)، اینکه یکمقداری از اطلاعات را به داتابیس وارد کنیم و بعدش کاربر منصرف بشه ،در داتابیس دستکاری کنیم این یکمقدار اضافه کاری به نظر میاد و لازم نیست (اگر لازم هست بگید، شاید من تا به حال به این مسعله مانند شما برنخوردم).

تا جایی که من میدونم اکسس ترانزکشن نداره، اگر به جایه اکسس از SqlServer Express استفاده کنید بهتر است.

Alireza Orumand

یک شنبه 04 آذر 1386, 16:53 عصر

سلام
آرژنگ عزیز سوال این بود

من در یکی از فرمهام کاربر چند نوع اطلاعات ثبت یا ویرایش میکنه و نهایتا تایید یا انصراف میکنه. برای انصراف راههترین راه چیه که تمام اون رکوردهای اضافه شده پاک بشوند و رکوردهای ویرایش شده به حالت قبل برگردند؟

وقتی ایشون گفت من تو یکی از فرم هام کاربر چند نوع اطلاعات ثبت یا ویرایش میکنه من اینطوری در نظر گرفتم که کاربر اول یه اطلاعاتی رو ثبت میکنه. حالا در مرحله ی بعد میره یا مجدد اطلاعات وارد میکنه یا اطلاعات ویرایش میکنه.
اینقدری که به ذهن من رسید اگر فرم جدیدی باز میشد که کاربر یک رکورد ثبت میکرد یا یک رکورد ویرایش خوب فرمایش شما درست بود که اگر وسط ثبت رکورد پشیمون میشد و هیچ کاری نمیکردیم ولی وقتی پای چند ثبت یا ویرایش میون میاد مثلا کاربر رکورد اول رو ثبت میکنه خوب الان اطلاعات از لایه ی بیزینس ارسال شده و بعد مجدد یه ویرایش یا ثبت انجام میده. حالا اگر پشیمون بشه با روش شما فقط آخرین مورد کنسل میشه و موارد قبلی مورد قبول هست برای همین من گفتم قبل از شروع کار یه transaction شروع کنن حالا هر چند تا رکورد که ثبت یا ویرایش کنن در صورت انصراف فقط یه roll back میکنن و یا در صورت تایید نهایی comit میشه و اگر مثلا کاربر 10 تا رکورد رو میخاد ثبت کنه و همگی باید ثبت بشه ولی بعد از ایجاد 5 رکورد سیستم از کار میوفته اون اطلاعاتی که ناقص وارد شدن roll back میشن.
دلیل من برای پیشنهاد transaction این بود که ایشون گفتن چند ثبت و چند ویرایش انجام میشه و وسط این ثبت و ویرایش ها منصرف میشه.

از اینکه به حالت کلکل جواب دادم پوزش عرض میکنم
اختیار دارید.

اَرژنگ

یک شنبه 04 آذر 1386, 17:37 عصر

سلام
آرژنگ عزیز سوال این بود

وقتی ایشون گفت من تو یکی از فرم هام کاربر چند نوع اطلاعات ثبت یا ویرایش میکنه من اینطوری در نظر گرفتم که کاربر اول یه اطلاعاتی رو ثبت میکنه. حالا در مرحله ی بعد میره یا مجدد اطلاعات وارد میکنه یا اطلاعات ویرایش میکنه.
اینقدری که به ذهن من رسید اگر فرم جدیدی باز میشد که کاربر یک رکورد ثبت میکرد یا یک رکورد ویرایش خوب فرمایش شما درست بود که اگر وسط ثبت رکورد پشیمون میشد و هیچ کاری نمیکردیم ولی وقتی پای چند ثبت یا ویرایش میون میاد مثلا کاربر رکورد اول رو ثبت میکنه خوب الان اطلاعات از لایه ی بیزینس ارسال شده و بعد مجدد یه ویرایش یا ثبت انجام میده. حالا اگر پشیمون بشه با روش شما فقط آخرین مورد کنسل میشه و موارد قبلی مورد قبول هست برای همین من گفتم قبل از شروع کار یه transaction شروع کنن حالا هر چند تا رکورد که ثبت یا ویرایش کنن در صورت انصراف فقط یه roll back میکنن و یا در صورت تایید نهایی comit میشه و اگر مثلا کاربر 10 تا رکورد رو میخاد ثبت کنه و همگی باید ثبت بشه ولی بعد از ایجاد 5 رکورد سیستم از کار میوفته اون اطلاعاتی که ناقص وارد شدن roll back میشن.
دلیل من برای پیشنهاد transaction این بود که ایشون گفتن چند ثبت و چند ویرایش انجام میشه و وسط این ثبت و ویرایش ها منصرف میشه.

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

Mrs.Net

یک شنبه 04 آذر 1386, 19:41 عصر

خداروشکر :لبخندساده:
تو یک قسمت از فرمم در حین ثبت اطلاعات یک فرم دیگه باز میشه و اونجا هم یه سری اطلاعات میگیره و برمیگرده به فرم اول و ادامه گرفتن اطلاعات در فرم اول... نکته مهم اینه که تا اطلاعات فرم دوم ثبت بانک نشه بقیه کار درست انجام نمیشه (لطفه نپرسید چرا :گریه:) پس مجبورم که ثبت کنم و ممکنه کاربر در آخر کار تصمصمش عوض بشه. چی میشه؟ باید اطلاعات فرم دوم از بانک برگرده (فقط مشکلم همین فرم دوم هست) و این کار راحتی نیست چون وقتی کاربر تو حالت ویرایش کردن اطلاعات قبلی باشه و چندتا رکورد از فرم دوم حذف کنه دیگه و منصرف بشه برگردوندنش کار خیلی پیچیده ای اما با ترازاکشن راحت برمیگرده ... امیدوارم متوجه شده باشید..
فرض کنید تمام طراحی درست هست و به موقع از لایه ها استفاده شده.:چشمک:
حالا لطفا به من کمک کنید که چجوری ترانزاکشن در سیستم سه لایه طراحی میشه (یه پست جدید زدم)
ممنون از همراهیتون

Alireza Orumand

یک شنبه 04 آذر 1386, 21:04 عصر

سلام

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

آرژنگ جان با توجه به اینکه تو سوال قید شده بود چند ثبت فکر کنم برداشت شما اشتباه بوده چون شما یه فرم رو فرض کن که توش یه فیلد نام از کاربر میگیری حالا کاربر یا باید 10 تا نام وارد کنه یا هیچی حالا کاربر اولین نام رو که وارد کرد باید چی کار کنه که بتونه نام بعدی رو وارد کنه؟ نمیخواید بگید که اگر ثبت کرد مقدار اون رو تو یه متغیر نگه داری میکنید و بعد با یه counter میشمرید تا وقتی 10 تا شد همه رو با هم یجا ارسال کنید و اگر کمتر بود همه متغیر ها رو دور میریزید.:متعجب:
مطمئنم جوابتون این نیست بلکه شما هم یه ترنزکشن شروع میکنید و هر اسمی که کار بر وارد کرد رو وارد دیتا بیس میکنید تا کاربر بتونه اسم بعدی رو وارد کنه و در نهایت اطلاعات رو comit یا roll back میکنید.
میدونم مثالم کمی دور از واقعیت بود ولی معمولا همین اتفاق ها میوفته.
حالا بریم سر جواب سوال
خوب این کار شما دقیقا با transaction انجام میشه.
دلیل اینکه اطلاعات فرم اول بدوم فرم دوم معنا نداره خوب مهم نیست میتونه دلیلی مثل همون مثال بانک باشه که بنده عرض کردم خدمتتون.
برای استفاده از transaction به این شکل عمل کنید.

BEGIN TRANSACTION
EXEC sp1
EXEC sp2
EXEC sp3
COMMIT TRANSACTION

تو این شرایط تا زمانی که هر سه sp کامل انجام نشه اطلاعات تو دیتابیس نمیمونه و شرط ثبت اطلاعات هم انجام بدون نقص هر سه مرحله هست.
اینم لینک مطالب مربوط به transaction تو books online
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/50a73574-1a69-448e-83dd-9abcc7cb7e1a.htm
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/c6258df4-11f1-416a-816b-54f98c11145e.htm
اینم برای roll back
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/tsqlref9/html/6882c5bc-ff74-476a-984b-164aeb036c66.htm
اگر مشکلی بود بپرسید.

Mrs.Net

یک شنبه 04 آذر 1386, 22:30 عصر

ممنون ولی استفاده از Transaction بلدم. میخوام نحوه پیاده کردن اون تو یک سیستم سه لایه و تحت لایه ی دیتا بدونم چجوری هست؟
درضمن OLEDB هم transaction داره

اَرژنگ

دوشنبه 05 آذر 1386, 00:59 صبح

سلام

آرژنگ جان با توجه به اینکه تو سوال قید شده بود چند ثبت فکر کنم برداشت شما اشتباه بوده چون شما یه فرم رو فرض کن که توش یه فیلد نام از کاربر میگیری حالا کاربر یا باید 10 تا نام وارد کنه یا هیچی حالا کاربر اولین نام رو که وارد کرد باید چی کار کنه که بتونه نام بعدی رو وارد کنه؟ نمیخواید بگید که اگر ثبت کرد مقدار اون رو تو یه متغیر نگه داری میکنید و بعد با یه counter میشمرید تا وقتی 10 تا شد همه رو با هم یجا ارسال کنید و اگر کمتر بود همه متغیر ها رو دور میریزید.:متعجب:
مطمئنم جوابتون این نیست بلکه شما هم یه ترنزکشن شروع میکنید و هر اسمی که کار بر وارد کرد رو وارد دیتا بیس میکنید تا کاربر بتونه اسم بعدی رو وارد کنه و در نهایت اطلاعات رو comit یا roll back میکنید.
من یک مثال ساده تر دازم، در برنامه نویسی وب، کاربر قراره یک مقاله بده، هر مقاله میتواند از صفر تا چندین عکس داشته باشد. نمیشه که اول از کاربر خواست که مقاله خالی را وارد کند که من یک آٓیدی براش بدست بیارم و بعدش عکسهاش را یکی یکی به این مقاله که حالا آیدی دارد اضافه کند، همه را با هم دریافت میکنیم و همه را با هم به لایه داتابیس میفرستیم.

اینکه کاربر یک یا چند تا چیز را قرار است وارد کند، خودش هم تا یک حدت ترانزکشن به حساب میاد، اگر مدل درست ساخته شده باشه، بله صبر میکنم تا کاربر بگه که میخواد همه نامها به ثبت برسند ، بعدش نامها را با تمام داتاهایه مربوطشان در یک ترانزکشان به داتابیس میفرستیم.
معمولا یک سری داتا که قرار است به داتا بیس وارد بشند باید کامل باشند، یعنی اینکه اگر قرار است با هر اسمی یک آدرسی باشد ، قبل از اینکه با ترانزکشن بخواهیم اسمها را فقط به داتابیس بفرستیمشان ، در لایه بیزینس چک میکنیم که هر کدام اطلاعات کامل را دارند.

استفاده از ترانزکشن برایه پیاده کردن منطق برنامه ما را به DataBase Development برمیگرداند، ولی استفاده از لایه بیزینس برایه چک کردن اینکه مدل ما کامل است متعلق به Application Development میباشد.

استفاده از ترانزکشن در برنامه ‌هایه کوچک و یک لایه برایه این دلیل شاید قابل قبول باشد، ولی در برنامه هایه بزرگتر از روشهایه دیگر استفاده میشه.

داتا باید در لایه بیزینس چک بشه و بعدش در حالت کامل بودن با یک ترانزکشن به پایگاه داده ثبت میشه.

Alireza Orumand

دوشنبه 05 آذر 1386, 08:56 صبح

سلام

من یک مثال ساده تر دازم، در برنامه نویسی وب، کاربر قراره یک مقاله بده، هر مقاله میتواند از صفر تا چندین عکس داشته باشد. نمیشه که اول از کاربر خواست که مقاله خالی را وارد کند که من یک آٓیدی براش بدست بیارم و بعدش عکسهاش را یکی یکی به این مقاله که حالا آیدی دارد اضافه کند، همه را با هم دریافت میکنیم و همه را با هم به لایه داتابیس میفرستیم.

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

ممنون ولی استفاده از Transaction بلدم. میخوام نحوه پیاده کردن اون تو یک سیستم سه لایه و تحت لایه ی دیتا بدونم چجوری هست؟
درضمن OLEDB هم transaction داره

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

اَرژنگ

دوشنبه 05 آذر 1386, 09:31 صبح

سلام

آرژنگ جان با توجه به اینکه تو سوال قید شده بود چند ثبت فکر کنم برداشت شما اشتباه بوده چون شما یه فرم رو فرض کن که توش یه فیلد نام از کاربر میگیری حالا کاربر یا باید 10 تا نام وارد کنه یا هیچی حالا کاربر اولین نام رو که وارد کرد باید چی کار کنه که بتونه نام بعدی رو وارد کنه؟ نمیخواید بگید که اگر ثبت کرد مقدار اون رو تو یه متغیر نگه داری میکنید و بعد با یه counter میشمرید تا وقتی 10 تا شد همه رو با هم یجا ارسال کنید و اگر کمتر بود همه متغیر ها رو دور میریزید.:متعجب:
مطمئنم جوابتون این نیست بلکه شما هم یه ترنزکشن شروع میکنید و هر اسمی که کار بر وارد کرد رو وارد دیتا بیس میکنید تا کاربر بتونه اسم بعدی رو وارد کنه و در نهایت اطلاعات رو comit یا roll back میکنید.

خیر! اگر با مفاهیم چند لایه کار کردن را بدانید میدونید که با متغییر کار نمیکنیم. با بیزینس ابجکتس کار میکنیم، یک مدل در حافظه میسازیم و تا موقعی که مدل قبول نکرده که تمام داتا را داره اصلا به لایه داتا نمیفرستیم که بخواهیم با ترانزکشن این کارها را انجام بدیم.
وقتی که بیزینس ابجکتها کامل تمام مقادیر را داشتند بعدش در لایه داتا با یک ترانزکشن همه تغییرات را در داتابیس انجام میدیم، ( در ضمن این روش حرفه‌ای است و من که نمیدونم، ولی اگر خواستید در چند کتاب و یا جاهایه مختلف این روش برایه شروع برنامه نویسی چند لایه‌ای تجویز میکنند!)

سلام

مثال شما یه مثال مسلم بود. مثل اینه که من بگم من اول از کاربر میخوام اسمش رو وارد کنه بعد از ورود اسم بگم فامیلی وارد کن.
شما بفرمایید روشی که شما پیشنهاد میکنید برای اون مثال بانک و مشتری یا همین مثالی که دوستمون ارائه کردن چه راه حلی پیشنهاد میده.

من گفتم که اگر بیزینس مدل درست باشد در لایه بیزینس تمام شرطها چک میشه و بعدش به لایه داتا صادر میشه، در لایه داتا تمام داتا در داخل یک ترانزکشن در داتابیس ثبت میشه. کجایه این برایه شما قابل قبول نیست؟

در ضمن کدام مثالی را که کدام دوست پیشنهاد کردند؟

در نهایت اشکال نداره. شما همینطوری به کار خودتون ادامه بدید. میگن آدمی که خوابه میشه بیدار کرد ولی کسی که خودش رو به خواب زده نه. کسی هم که نخواد حرفی رو قبول کنه قبول نمیکنه.

این بهترین جوابی است که برایه درست بودن روشتان دارید؟ به جایه این حرفها یک پروژه کوچک که روشتان را نشان بده بفرستید که ما هم از خواب بیدار بشیم!

حرف شما بر چه اساسی قبول کنیم؟ دلیل کو، مدرک کو؟ یک مثال ساده یا منبع معتبر خواستید بفرستید.
اگر به برنامه نویسی لایه‌ای آشنا هستید این روشی که پیشنهاد میکنید را خودتان با برنامه نویسی ۳ لایه امتحان کردید؟ اآخه یک تیکه کد دادن انقدر سخته؟

تا اینجا امیدوار بودم که حرف هایی که زده میشه نتیجه داشته باشه ولی نمیده. ترجیح میدم به جای ادامه این بحث که هیچ فایده ای نداره به کارهای مثبت برسم. شما هم اگر کار حرفه ای برنامه نویسی انجام بدید بالاخره تو یه پروژه متوجه میشید که کار اشتباه همیشه قابل پیاده سازی نیست.:چشمک:
موفق باشید.
کاره اشتباه؟ شما هنوز کار درست را با یک مثال ساده پیاده سازه نکردید که ما هم سود ببریم!

به جایه اینکه حرفه‌ای و یا غیره حرفه‌ای بودن من را سوال کنید، یک مثال ساده بدید که ما هم این روش حرفه‌ای را ببینیم.
در ضمن لطفا اگر کدی و یا پروژه‌ای و یا لینکی به یک مقاله‌ای که این روش شما را توجیح میکند ندارید بیزحمت به این بحث ادامه ندید، چونکه ماه ما هم کلی کارهایه مثبت دیگر برایه انجام دادن داریم تا اینکه سر روشهایه بدون دلیل و مدرک و بدونه مثال بحث کنیم.

Alireza Orumand

دوشنبه 05 آذر 1386, 13:41 عصر

سلام

خیر! اگر با مفاهیم چند لایه کار کردن را بدانید میدونید که با متغییر کار نمیکنیم. با بیزینس ابجکتس کار میکنیم، یک مدل در حافظه میسازیم و تا موقعی که مدل قبول نکرده که تمام داتا را داره اصلا به لایه داتا نمیفرستیم که بخواهیم با ترانزکشن این کارها را انجام بدیم.
وقتی که بیزینس ابجکتها کامل تمام مقادیر را داشتند بعدش در لایه داتا با یک ترانزکشن همه تغییرات را در داتابیس انجام میدیم، ( در ضمن این روش حرفه‌ای است و من که نمیدونم، ولی اگر خواستید در چند کتاب و یا جاهایه مختلف این روش برایه شروع برنامه نویسی چند لایه‌ای تجویز میکنند!)

عزیزم به اعصاب خودت مسلط باش. اتفاقی نیوفتاده که شما اینقدر عصبانی میشی. من برنامه نویسی بلد نیستم که بخوام کد نمونه بدم. شرمنده که تو بحث با شما حرفه ای وارد شدم.

من گفتم که اگر بیزینس مدل درست باشد در لایه بیزینس تمام شرطها چک میشه و بعدش به لایه داتا صادر میشه، در لایه داتا تمام داتا در داخل یک ترانزکشن در داتابیس ثبت میشه. کجایه این برایه شما قابل قبول نیست؟

اما اصول data base به ما میگه که وقتی داده ای قراره تو دیتا بیس ثبت بشه باید قوانینی که مد نظر ما هست روی اون اعمال بشه. مثلا اگر سنی برای کسی قراره ثبت بشه اون سن نباید منفی باشه. یا اگر دسته ای از اطلاعات وابسته به دسته ای دیگه بودن اگر دسته ی اول ثبت شد و بعد دسته دوم نتونست ثبت بشه باید دسته اول هم حذف بشه. تا اینجاشو که ایشالا قبول دارید؟
خوب اگر قبول داشتید به این موضوع فکر کنید که شما یه پایگاه داده طراحی میکنید. بعد با توجه به حرفه ای بودنتون و با استفاده از اصول طراحی سه لایه یک برنامه مینویسید و همونطور که خودتون فرمودید تمامی شرط ها رو در لایه ی بیزینس چک میکنید. تا اینجا برنامه شما درسته. بعد شرکت بزرگ میشه و چند تا شعبه میزنه و برای کار تصمیم میگریه دیتابیس رو روی اینترنت بگذاره و هرکدوم از شعبه ها داده ها رو داخل این پایگاه ثبت کنن. بنده ی بی سواد هم برنامه نویس شعبه ی شرکت تو کشور ترینیدادتوباگو هستم. به من میگن یه برنام بنویس که به این دیتا بیس وصل بشه و ما اطلاعات رو ثبت کنیم. من هم که برنامه نویسی سه لایه بلد نیستم و تا قسمتی هم ناشی هیچ کدوم از شرایطی که شما در بیزینس لایر چک کردید رو چک نمیکنم. حالا چه اتفاقی میوفته اطلاعات بدون اینکه تایید شده باشن وارد دیتابیس شما میشه. حالا شما که زیاد کتاب خوندید و برای مبتدی ها کتاب تجویز میکنید میشه مقاله یا کتاب معرفی کنید که توی اون تضمین کرده باشه که همیشه همه برنامه نویس ها که با بانک ما کار میکنن شرایط رو تو برنامه چک میکنن.
نکته این مثالی که من زدم این بود که این اتفاق واقعا برای شرکتی که بعد از مدتی فعالیت تو ایران رشد کرد و شعبه ای تو کشور اینگلیس زد رخ داد.

در ضمن کدام مثالی را که کدام دوست پیشنهاد کردند؟
خوب همین دیگه اصلا انصافا شما کل مطالب رو خوندی؟ یادته گفتم فقط باید بدون تعصب یه بار دیگه مطلب رو بخونیم. با این حرفی که زدید مطمئن شدم شما هرگز این کار رو نکردید.

به جایه اینکه حرفه‌ای و یا غیره حرفه‌ای بودن من را سوال کنید، یک مثال ساده بدید که ما هم این روش حرفه‌ای را ببینیم.

من مثال خودم رو زدم هم تو همین پست هم تو مثال های قبلی. شما اصلا مطلب رو نمیخونید بعد شروع میکنید جواب دادن دیگه من کاریش نمیتونم بکنم. البته فهمیدن اینکه مطالب رو کامل نمیخونید زیاد سخت نیست. برای مثال دوتا پست اخیر خودت رو یه نگاه بنداز یه بخش از حرف رو دوبار نقل قول کردید و هر بار توضیحی دادید. میدونید چرا؟ یه بار خوندید یه نتیجه گرفتید و بار دیگه خوندید یه نتیجه دیگه گرفتید.
برای بیداری از خواب هم شما یه زحمت بکشید مقاله یا کتابی که تضمین کننده چک شدن شرایط باشه پیدا کنید و برای من بفرستید ایشالا بیدار میشید.

به جایه اینکه حرفه‌ای و یا غیره حرفه‌ای بودن من را سوال کنید، یک مثال ساده بدید که ما هم این روش حرفه‌ای را ببینیم.
در ضمن لطفا اگر کدی و یا پروژه‌ای و یا لینکی به یک مقاله‌ای که این روش شما را توجیح میکند ندارید بیزحمت به این بحث ادامه ندید، چونکه ماه ما هم کلی کارهایه مثبت دیگر برایه انجام دادن داریم تا اینکه سر روشهایه بدون دلیل و مدرک و بدونه مثال بحث کنیم.

کد یا مقاله یا لینک دارم. برای این منظور شما پیش از اینکه وارد مقوله ی برنامه نویسی چند لایه بشید اول چند تا کتاب درباره طراحی پایگاه داده و اصول اون بخونید بعد وارد مقوله برنامه نویسی چند لایه بشید. آخه وقتی ما برای دیتابیس برنامه می نویسیم مهم ترین بخش کار اطلاعات هستن و تضمین صحت اطلاعات. در چنین مواردی اصول پایگاه داده که با صحت اطلاعات مرتبط هستن نسبت به اصول برنام نویسی چند لایه برتری دارن و شما که حرفه ای هستید میدونید که بدون رعایت اصول برنام نویسی چند لایه هم میشه برنامه ای نوشت که با رعایت اصول دیتابیس صحت اطلاعات رو برای ما تضمین میکنه ولی بدون رعایت اصول دیتابیس هر چقدر هم که برنامه ما چند لایه باشه باز هم مهم ترین بخش کار یعنی اطلاعات و داده ها ممکنه اشتباه باشه.
این چیزهایی بود که به نظر این بی سواد میرسید. شما هم خودتو زیاد ناراحت نکن من بچگی کردم یه چیزی گفتم شما ناراحت نشو.
موفق باشید.

اَرژنگ

دوشنبه 05 آذر 1386, 14:19 عصر

به من میگن یه برنام بنویس که به این دیتا بیس وصل بشه و ما اطلاعات رو ثبت کنیم. من هم که برنامه نویسی سه لایه بلد نیستم و تا قسمتی هم ناشی هیچ کدوم از شرایطی که شما در بیزینس لایر چک کردید رو چک نمیکنم. حالا چه اتفاقی میوفته اطلاعات بدون اینکه تایید شده باشن وارد دیتابیس شما میشه. حالا شما که زیاد کتاب خوندید و برای مبتدی ها کتاب تجویز میکنید میشه مقاله یا کتاب معرفی کنید که توی اون تضمین کرده باشه که همیشه همه برنامه نویس ها که با بانک ما کار میکنن شرایط رو تو برنامه چک میکنن

در برنامه نویسیه لایه‌ای همینطوری به کسی نمیگند که بیا به این داتابیس وصل شو، فقط برنامه نویسانی که با لایه داتا کار میکنند اجازه وصل شدن به داتابیس را دارند.
کسانی که میخواند از سیستم اضافه کنند به لایه بیزینس از راهها مختلف وصل میشند، وب سرویس، رموتینگ و یا هر روش دیگری، هیچ‌ کی همینطوری نمیاد داتابیسش را باز بزاره که هر کی هر جوری دلش خواست داتا را همینطوری بریزه توش.
لازم نیست من تضمین کنم که همیشه همه برنامه نویس ها که با بانک ما کار میکنن شرایط رو تو برنامه چک میکنن! اصلا به جز برنامه نویسان داخلی که با لایه داتا کار میکنند کسی حق ندارد که به داتابیس وصل بشد،
اینکه شما میگید : "به من میگن یه برنام بنویس که به این دیتا بیس وصل بشه و ما اطلاعات رو ثبت کنیم. من هم که برنامه نویسی سه لایه بلد نیستم و تا قسمتی هم ناشی هیچ کدوم از شرایطی که شما در بیزینس لایر چک کردید رو چک نمیکنم" برنامه نویسی لایه ‌ای برایه این نیست که شما لایه بیزینس را دوباره پیاده کنید! شما فقط میتوانید در حالتی که لایه بیزینش از لحاض امنیتی شما را قبول کند باهاش تبادل اطلاعات کنید. فایده بیزینس لایر هم همینه.
شما لازم نیست لایه نویسی بلد باشید و یا اینکه در مورد داتابیس، بیزینش لایر و یا اینکه چطوری پیاده شدند هیچ‌ چی بدانید، فقط یک سری ای.پی.ای در اختیارتان است که به لایه بیزینس به هر طریقی که گفتند تبادل اطلاعات کنید، همین.

در ضمن مخلصتان هم هستیم:چشمک:

Alireza Orumand

دوشنبه 05 آذر 1386, 15:44 عصر

سلام
حرف گوش نمیکنی:چشمک: این مطلب دیگه جدا آخرین مطلبی که من میگم.
1-Presentation Layer که ما کاری نداریم.
میمونه دوتا لایه دیگه Business Logic و Data Access خوب کار این دوتا رو هم که شما بهتر از من میدونید.
برنامه هایی مثل sql server که من از اول دارم باهاش مثال میزنم هر دوی این لایه ها رو پوشش میده. یعنی چی یعنی شما تو server میتونی هم اعتبار سنجی کنید هم ثبت.
در این شرایط من میگم که بهتره هر دوی این لایه ها تو سرور باشه و اینطوری اعتبار سنجی عضو لاینفک پایگاه داده ای ما میشه.
حالا شما میگید چی میگید همونطور که برای Presentation داریم برنامه مینویسیم بیام برای Business Logic هم برنامه بنویسیم.
در هر صورت ما داریم از برنامه نویسی سه لایه استفاده میکنیم ولی به دوشکل مختلف.
شما یه دیتابیس میسازید که میشه Data Access. بعد میاید به کمک برنامه نویسی Business Logic و Presentation رو درست میکنید. حالا اگر پایگاه داده شما(یک در هزار احتمالش وجود داشته باشه) که تنها Data Access هست در اختیار کسی قرار بگیره اون میتونه بدون رعایت قوانین اطلاعات وارد دیتابیس کنه.
ولی من یه دیتا بیس میسازم که Data Access و Business Logic رو با هم پیاده سازی میکنم و بعد میام به کمک برنامه نویسی Presentation رو درست میکنم. حالا اگر پایگاه داده ی من(یک در هزار) بدون برنامه ای که من نوشتم در اختیار کسی قرار بگیره باز هم نمیتونه بدون گذشتن از Business Logic اطلاعاتی وارد دیتابیس من بکنه.
یه مثال دیگه بزنم:
یه دیتا بیس داریم که سه تا اسم باید توش ثبت بشه مثلا علی، حسن، حسین.
ولی یه شرط داره و اون اینکه اول علی باید باشه تا حسن بیاد و حسن باید باشه تا حسین بیاد.
کاری که شما دارید از اون صحبت میکنید اینه. بعد از اینکه حسن اسمش رو وارد کرد میرید تو دیتابیس نگاه میکنید ببینید علی هست یا نه اگر بود اجازه میدید ثبت بشه و اگر نبود اجازه این کار رو نمیدید.
من این کار رو چطوری انجام میدم یه تریگر میگذارم و شرط رو تو تریگر چک میکنم.
حالا اگر کسی بیاد دیتابیس شما رو با management studio باز کنه میتونه بدون وارد کردن علی حسن رو وارد کنه ولی اگر دیتا بیس من رو باز کنه نمیتونه این کار رو بکنه.
حرف من از اول این بود که تا جایی که محیط به اجازه میده باید Business Logic رو جایی قرار بدیم که نشه از data acces جدا کرد.
برای پیاده سازی برنامه سازی سه لایه حتما نباید لایه ی Business Logic به کمک برنامه نویسی پیاده سازی بشه.
حالا انصافا این بار رو بدون ناراحتی بخون من جایی تو کارم اصول برنامه نویسی سه لایه رو نقض کردم؟
یه سوال دیگه هم بدون تعصب جواب بدید. آیا اگر دیتابیس شما تحت هر شرایطی بدون API هایی که شما ساختید در اختیار دیگری قرار بگیره اصول طراحی دیتابیس رو نقض نکرده؟
به نظر من یه اشتباهی رایج هست و اون اینکه وقتی اسم برنامه نویسی سه لایه میاد همه فکر میکنن باید یه دیتابیس درست کنن و برای دو لایه ی دیگه کد بنویسن ولی اینطور نیست.
در تعریف Business Logic ما داریم که باید صحت اطلاعات رو بررسی کنیم. ولی گفته نشده که برای مثال حتما باید تو کد c# این کار انجام بشه. فقط صحت اطلاعات مهم هست.
محیط های توسعه پایگاه داده مثل sql server امکان بررسی صحت اطلاعات رو به ما میدن. یعنی امکان پیاده سازی لایه ی دوم. حالا پیاده سازی لایه ی دوم تو sql server که به معنی نادیده گرفتن اصول برنامه نویسی سه لایه نیست بلکه به نظر این حقیر این خود برنامه نویسی سه لایه هست. فقط با این کار برنامه ما از نظر منطقی استحکام بیشتری پیدا میکنه.
آرژنگ عزیز من از اول دارم تلاش میکنم این موضوع رو برسونم که اگر محیط توسعه دیتابیس امکان پیاده سازی Business Logic رو به ما میده خوب ما باید از این امکان استفاده کنیم تا Business Logic همیشه و تحت هر شرایطی همراه data acces باشه. به نظر حقیر اگر این کار تو برنامه نویسی انجام بشه اتفاق خاصی نمیوفته ولی میشه بدون Business Logic از data access استفاده کرد. این که Business Logic حتما باید با برنامه نویسی ایجاد بشه به نظر من اشتباه هست و من به هر کدوم از دوستانم که این تفکر رو دارن گفتم که اشتباه هست. شما هم چون جزء برنامه نویس های ایرانی هستی دوست من هستی و من تلاش کردم که این تفکر اشتباه از ذهن شما برداشته بشه. به قول شاعر
من آنچه شرط بلاغ بود با تو گفتم تو خواه پند گیر و خواه ملال.
به نظر من تو روش پیاده سازی شما تا زمانی که هر سه لایه با هم باشن اشکالی وجود نداره ولی اگر کسی به لایه ی سوم دسترسی پیدا کنه شما کارتون به مشکل میخوره.
این هم آخرین عرض این حقیر. امیدوارم از لحاظ علمی مشکلی نداشته باشه و تونسته باشه شما رو متقاعد کنه.
موفق و سربلند باشید

اَرژنگ

سه شنبه 06 آذر 1386, 11:42 صبح

سلام
حرف گوش نمیکنی:چشمک: این مطلب دیگه جدا آخرین مطلبی که من میگم.
1-Presentation Layer که ما کاری نداریم.
میمونه دوتا لایه دیگه Business Logic و Data Access خوب کار این دوتا رو هم که شما بهتر از من میدونید.
برنامه هایی مثل sql server که من از اول دارم باهاش مثال میزنم هر دوی این لایه ها رو پوشش میده. یعنی چی یعنی شما تو server میتونی هم اعتبار سنجی کنید هم ثبت.
در این شرایط من میگم که بهتره هر دوی این لایه ها تو سرور باشه و اینطوری اعتبار سنجی عضو لاینفک پایگاه داده ای ما میشه.
حالا شما میگید چی میگید همونطور که برای Presentation داریم برنامه مینویسیم بیام برای Business Logic هم برنامه بنویسیم.
در هر صورت ما داریم از برنامه نویسی سه لایه استفاده میکنیم ولی به دوشکل مختلف.
شما یه دیتابیس میسازید که میشه Data Access. بعد میاید به کمک برنامه نویسی Business Logic و Presentation رو درست میکنید. حالا اگر پایگاه داده شما(یک در هزار احتمالش وجود داشته باشه) که تنها Data Access هست در اختیار کسی قرار بگیره اون میتونه بدون رعایت قوانین اطلاعات وارد دیتابیس کنه.
ولی من یه دیتا بیس میسازم که Data Access و Business Logic رو با هم پیاده سازی میکنم و بعد میام به کمک برنامه نویسی Presentation رو درست میکنم. حالا اگر پایگاه داده ی من(یک در هزار) بدون برنامه ای که من نوشتم در اختیار کسی قرار بگیره باز هم نمیتونه بدون گذشتن از Business Logic اطلاعاتی وارد دیتابیس من بکنه.
یه مثال دیگه بزنم:
یه دیتا بیس داریم که سه تا اسم باید توش ثبت بشه مثلا علی، حسن، حسین.
ولی یه شرط داره و اون اینکه اول علی باید باشه تا حسن بیاد و حسن باید باشه تا حسین بیاد.
کاری که شما دارید از اون صحبت میکنید اینه. بعد از اینکه حسن اسمش رو وارد کرد میرید تو دیتابیس نگاه میکنید ببینید علی هست یا نه اگر بود اجازه میدید ثبت بشه و اگر نبود اجازه این کار رو نمیدید.
من این کار رو چطوری انجام میدم یه تریگر میگذارم و شرط رو تو تریگر چک میکنم.
حالا اگر کسی بیاد دیتابیس شما رو با management studio باز کنه میتونه بدون وارد کردن علی حسن رو وارد کنه ولی اگر دیتا بیس من رو باز کنه نمیتونه این کار رو بکنه.
حرف من از اول این بود که تا جایی که محیط به اجازه میده باید Business Logic رو جایی قرار بدیم که نشه از data acces جدا کرد.
برای پیاده سازی برنامه سازی سه لایه حتما نباید لایه ی Business Logic به کمک برنامه نویسی پیاده سازی بشه.
حالا انصافا این بار رو بدون ناراحتی بخون من جایی تو کارم اصول برنامه نویسی سه لایه رو نقض کردم؟
یه سوال دیگه هم بدون تعصب جواب بدید. آیا اگر دیتابیس شما تحت هر شرایطی بدون API هایی که شما ساختید در اختیار دیگری قرار بگیره اصول طراحی دیتابیس رو نقض نکرده؟
به نظر من یه اشتباهی رایج هست و اون اینکه وقتی اسم برنامه نویسی سه لایه میاد همه فکر میکنن باید یه دیتابیس درست کنن و برای دو لایه ی دیگه کد بنویسن ولی اینطور نیست.
در تعریف Business Logic ما داریم که باید صحت اطلاعات رو بررسی کنیم. ولی گفته نشده که برای مثال حتما باید تو کد c# این کار انجام بشه. فقط صحت اطلاعات مهم هست.
محیط های توسعه پایگاه داده مثل sql server امکان بررسی صحت اطلاعات رو به ما میدن. یعنی امکان پیاده سازی لایه ی دوم. حالا پیاده سازی لایه ی دوم تو sql server که به معنی نادیده گرفتن اصول برنامه نویسی سه لایه نیست بلکه به نظر این حقیر این خود برنامه نویسی سه لایه هست. فقط با این کار برنامه ما از نظر منطقی استحکام بیشتری پیدا میکنه.
آرژنگ عزیز من از اول دارم تلاش میکنم این موضوع رو برسونم که اگر محیط توسعه دیتابیس امکان پیاده سازی Business Logic رو به ما میده خوب ما باید از این امکان استفاده کنیم تا Business Logic همیشه و تحت هر شرایطی همراه data acces باشه. به نظر حقیر اگر این کار تو برنامه نویسی انجام بشه اتفاق خاصی نمیوفته ولی میشه بدون Business Logic از data access استفاده کرد. این که Business Logic حتما باید با برنامه نویسی ایجاد بشه به نظر من اشتباه هست و من به هر کدوم از دوستانم که این تفکر رو دارن گفتم که اشتباه هست. شما هم چون جزء برنامه نویس های ایرانی هستی دوست من هستی و من تلاش کردم که این تفکر اشتباه از ذهن شما برداشته بشه. به قول شاعر
من آنچه شرط بلاغ بود با تو گفتم تو خواه پند گیر و خواه ملال.
به نظر من تو روش پیاده سازی شما تا زمانی که هر سه لایه با هم باشن اشکالی وجود نداره ولی اگر کسی به لایه ی سوم دسترسی پیدا کنه شما کارتون به مشکل میخوره.
این هم آخرین عرض این حقیر. امیدوارم از لحاظ علمی مشکلی نداشته باشه و تونسته باشه شما رو متقاعد کنه.
موفق و سربلند باشید
به این میگند برنامه نویسی ۲ لایه.
از اینکه زحمت کشیدید و این مطالب را نوشتید متشکرم، ولی این موضوع قبلا بحث شده بود.
برنامه نویسی ۲ لایه کمبودهایه زیادی دارد که برایه پروژه‌هایه معمولی قابل قبول نیست.
برنامه نوسیه ۳ لایه تازه اول کار است و یکی از پروژهایه آزاد یک فریم ورک برایه برنامه نویسی ۵ لایه است http://www.lhotka.net/cslanet/.

"اگر کسی به لایه ی سوم دسترسی پیدا کنه شما کارتون به مشکل میخوره"
اگر در شرکتهایه بزرگ کار کنید میبیند که احتمال همچین اتفاقی صفر است.

هر کی فکراش برایه خودش کامله، ولی با یکمقداری مطالعه با خیلی از چیزهایی یک عمر هم بهشان فکر نمیکرد مواجه میشه، اگر وقت کردید یکمقداری در مورد برنامه نویسی چند لایه (n-Tier Programming) مطالعه کنید بعدش اگر هنوز هم باور به این داشتید که ۲ لایه بس است ما گوش خواهیم بود.

Alireza Orumand

سه شنبه 06 آذر 1386, 18:17 عصر

به این میگند برنامه نویسی ۲ لایه.

والا تو تعریف برنامه نویسی 3 لایه میگن برنامه به سه بخش تقسیم میشه که این سه بخش میتونه فیزیکی یا منطقی باشه. حتی برنامه شما میتونه در یک فایل باشه ولی از نظر منطقی به سه لایه ی مختلف تقسیم شده باشه. و میشه برنامه شما از سه بخش تشکیل شده باشه ولی از نظر منطق یک لایه باشه که این دیگه منتفی میشه.
یه سوال دارم آیا زبانی که با او لایه ی Business Logic رو پیاده سازی میکنیم مهمه؟
تا جایی که من میدونم هیچ تفاوتی نمیکنه که برنامه با چه زبونی نوشته بشه.
خوب حالا بریم سر اصل مطلب. شما برنامه خودتون رو از نظر منطقی به سه لایه تقسیم میکنید و از نظر فیزیکی هم همینطور. من برنامه خودم رو به سه لایه تقسیم کردم و از نظر فیزیکی دو لایه.
شما لایه ی دوم رو با c# پیاده سازی کردید من با TSQL.
حالا یه سوال دیگه که اگر جواب دادید من فرمایش شما رو قبول میکنم.
من لایه ی سوم خودم رو با زبان sql درست کردم. زبان sql هم همونطور که در جریان هستید دو بخش دراه. یکی DML یا استفاده از داده ها که کارهایی مثل insert و delet هست و بخش دیگه DDL یا تعریف داده ها که مثل creat table.
حالا اگر میشه به این سوال جواب بدید که فایر شدن یه تریگر جزء کدوم یکی از این دستورات هست.
یا وقتی من میخوام یه فیلد int همیشه بزرگتر از 10 باشه و این شرط رو روی فیلد میگذارم وقتی من یه مقدار میخوام وارد جدول کنم قبل از اینکه این مقدار وارد بشه یعنی قبل از اینکه insert انجام بشه این شرط چک میشه. چک شدن این شرط جزء کدوم یکی از این دوبخش هست dml یا ddl؟
در نهایت باز هم من میگم من لایه ی دوم خودم رو با زبان T-SQL پیاده سازی کردم و شما با c#.
دو تا لایه ی جدا هست. من sp ها و تریگر های خودم رو به طور جدا گانه دارم و بدون دست کاری توی ساختار دیتا بیسم میتونم اونها رو ویرایش کنم. شما هم همی کار رو میکنید. فقط شما اگر لایه ی دوم رو اطلاح کنید باید باید یه بار دیگه کلاستون رو بیلد کنید و نه به برنامه کاربر دست میزنید نه به پایگاه داده. من لایه ی دوم رو تغییر میدم باید تریگر یا sp خودم رو بسازم و به دو لایه ی دیگه کاری ندارم. این یعنی برنامه من از لحاظ فیزیکی هم جدا هست.

اگر در شرکتهایه بزرگ کار کنید میبیند که احتمال همچین اتفاقی صفر است.

بعد شرکت بزرگ میشه و چند تا شعبه میزنه و برای کار تصمیم میگریه دیتابیس رو روی اینترنت بگذاره و هرکدوم از شعبه ها داده ها رو داخل این پایگاه ثبت کنن.

فکر کنم شرکتی که براش کار میکردم زیاد کوچیک نبود. و الان هم ...
موفق باشید

اَرژنگ

چهارشنبه 07 آذر 1386, 01:41 صبح

بنابر اینهایی که گفتید ۳ لایه کار میکنید، و اینکه از چه زبانی استفاده شده مهم نیست.

ولی یک سوال که پیش آمد این است که چطور همه به همان بانک دسترسی دارند؟ مشکلات امنیتی را چطوری حل کردید؟ چک کردن بعضی از داده ها مانند ایمیل و شماره تلفن قبل از وارد کردن به داتابیس با سی شارپ راحتتر نیست؟‌ اینها را چطوری چک میکنید.

چند وقت پیش یکی از اساتید اینجا گفتند که مقدار کار با داتابیس‌ها به اندازه‌ای پیشرفت کرده که یکمقداری از لایه بیزینس را در داتابیس قرار میدند، ولی قرار دادن تمام لایه منطق در داتابیس جالب است.

یعنی فقط یک داتابیس وجود دارد و همه مستقیما به همان داتابیس مرکزی وصل میشند؟
از چه داتابیسی استفاده میشه که انقدر انعتاف پزیر است؟

اگر از SqlServer 2005 استفاده میکنید(؟) (اراکل نه!)، و قابلیت انجام همه اینکارها را میگید دارد، فکر کنم وقتش رسیده یکمقداری ترانزاکت اس کیو ال و قابلیتهایه SqlServer 2005 را مطالعه کنم.

ببخشید، ولی ترک طرز فکری آسان نیس، تعصب روش انجام دادن جلویه فهمیدن اینکه چی دارید میگید را گرفته بود.

مرسی!

Alireza Orumand

چهارشنبه 07 آذر 1386, 11:49 صبح

چک کردن بعضی از داده ها مانند ایمیل و شماره تلفن قبل از وارد کردن به داتابیس با سی شارپ راحتتر نیست؟‌ اینها را چطوری چک میکنید.

این کار کمی سلیقه ای است. شما با توجه به تسلط و توانایی هایی که تو c# دارید این فرمایش رو میفرمایید ولی اگر کسی مثل شما تو c# توانا نباشه ولی در عوض خیلی تو tsql مهارت داشته باشه نظرش متفاوته.
در مورد چکونگی کار هم مثال مناسبی به ذهنم نمیرسه اگر دوست داشتید یه نمونه با c# بگذارید من با tsql پیاده سازی میکنم.

یعنی فقط یک داتابیس وجود دارد و همه مستقیما به همان داتابیس مرکزی وصل میشند؟

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

از چه داتابیسی استفاده میشه که انقدر انعتاف پزیر است؟
sql server

اگر از SqlServer 2005 استفاده میکنید(؟) (اراکل نه!)، و قابلیت انجام همه اینکارها را میگید دارد، فکر کنم وقتش رسیده یکمقداری ترانزاکت اس کیو ال و قابلیتهایه SqlServer 2005 را مطالعه کنم.

اگر در انجام این کار جدی هستید و منبع مناسب ندارید من خوشحال میشم منابعی که دارم در اختیار شما قرار بدم.
موفق و سربلند باشید.