محل قرارگیری کلاس های entity و exception در معماری سه لایه

[trustmiracle]

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

من یک فرم دارم که کاربر در اون نام کاربری، کلمه عبور، نام مستعار و ایمیلش را وارد می کنه و روی دکمه ثبت کلیک می کنه. خوب این فرم من میشه لایه presentation. من کلاس فرم را به شکل زیر در نظر می گیرم:


Form Register{
public void show(){
//init ang show form
}

public void register(){
String username= txtUser.getText();
String password= txtPass.getText();
String email=txtEmail.getText();
String nickname=txtNickname.getText();

RegisterBLL rbll=new RegisterBLL().
boolean s=rbll.register(username, password, email, nickname);

if (s)
showSuccess();
else
showError();
}

private void showSuccess(){
//show success message
}

private void showError(){
//show fail message
}
}


خوب پس همانطور که دیدین پس از فشرده شدن دکمه Register تابع معادل صدا زده شد و پس از دریافت مقادیر وارد شده اون ها را به تابع Register از کلاس RegisterBLL ارسال کرد. کلاس RegisterBLL توی لایه Business هست و این هم کدش:



class RegisterBLL{

public boolean Register(String username, String password, String email, String nickname){
User user=new User(username, password, email, nickname);
boolean s=user.validateFields();
if (!s)
return false;

UserDAL udal=new UserDAL();
s=udal.checkExists(user);
if (!s)
return s;

s=udal.add(user);
if (!s)
return false;

return true;
}

}


خوب همین طور که ملاحظه کردین من در این تابع ابتدا یک نمونه از کلاس user تعریف کردم و اون را با پارامترهایی که به تابع ارسال شده مقدار دهی کردم. بعد چک کردم که مقادیر معتبر باشند. بعد با استفاده از کلاس UserDal که در لایه دسرتسی به داده است چک کردم که یوزر تکراری نباشه و بعد هم تثبتش کردم. خوب حالا چرا من در لایه نمایش یک نمونه از کلاس user نساختم و داده ها را به صورت پارامترهای رشته ای به لایه business ارسال کردم؟ چون اون موقع کلاس user که entity من هست باید توی لایه نمایش تعریف میشد اون وقت دیگه لایه DAL نمی تونست ازش استفاده کنه. چون هر لایه به کلاس های هم لایه یا لایه زیرین خودش دسترسی داره. پس من کلاس user را تو لایه DAL تعریف کردم تا هم لایه نمایش بهش دسترسی داشته باشه و هم لایه دسترسی به داده.
مورد دوم آیا هر لایه باید کلاس های exception مخصوص به خودش را داشته باشه؟ چون اگر توی لایه دسترسی به داده من یک exception تولید کنم کلاسش را فقط لایه نمایش تشخیص میده. و برای اینکه لایه نمایش این exception را به لایه نمایش اطلاع بده باید یک exception ای که تو خود این لایه تعریف شد پرتاب بشه.

خیلی سعی کردم سوال و درکم را واضح بیان کنم. پیشاپیش از لطفتان ممنونم.

[cups_of_java]

منظور شما از 3 لایه فکر کنم 3-tier به معنای Presentation/Business/Data Access هستش!؟ این معماری بیشتر یه معماری فیزیکی هستش نه الگویی که توی کد شما دیده بشه. شما موضوع رو بیشتر باید بر اساس الگوی MVC بررسی کنی.
User یک کلاس Entity می تونه باشه و در لایه Data تعریف شه و مشکلی نیست که از تو لایه Presentation مورد استفاده قرار بگیره.
این هم که شما برای هر لایه Exception خاص خودشو درست بکنی یا نه به بزرگی و پیچیدگی برنامت ربط داره. اصولن همچین کاری برای خیلی از برنامه ها عرف نیست و کارتو سخت تر می کنه.
بعدم این لایه ها هیچ کدوم زیر هم دیگه نیستن به معنای لایه های زیرینی که شما گفتی! میشه واضح تر سوالت رو بپرسی؟

[trustmiracle]

بله منظور من همان معماری 3-tier هست. این مدلی که من از این معماری دیدم:

http://imrasta.persiangig.com/image/software_engineering/n-tier/3-tier.png

خوب ببینین تو این مدل لایه نمایش مستقیما به مدل DAL دسترسی نداره. پس اگر entity ها توی DAL تعریف بشه از توی DAL و BLL قابل دسترسی هست ولی از توی PL قابل دسترسی نیست. اگر هم توی BLL تعریف بشه توی BLL و PL قابل دسترسی هست و توی DAL قابل دسترسی نیست. حالا من می خواستم ببینم اصلا حالت استانداردش به چه صورت است؟ توی کدام لایه تعریف میشه. حالا من یک چیزی به ذهنم رسید میشه ما یک لایه دیگه اضافه کنیم که entity ها را داخلش اضافه کنیم و همچنین exception ها را و هر سه لایه بهش دسترسی داشته باشند؟ من به نظرم میاد تنها عیبش افزایش وابستگی لایه ها به هم باشه. آیا این به نظرتان عیب دیگری هم داره؟ چیزی شبیه شکل زیر مدنظرم هست

http://imrasta.persiangig.com/image/software_engineering/n-tier/pic1.png
http://barnamenevis.org/image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAX8AAAEBCAIAAAA fDjKBAAAPGklEQVR4nO3b22GkSgyE4YlrA3I8G42T2WBmH2zL4 t6AQOri/96O50KXGmpnsM/rDQAZXtkLAPBQtA+AHLQPgBy0D4ActA+AHLQPgBy0D4ActA+AH LQPgByt7fMCgFW0D4ActA+AHLQPgBy0D4AcN7XP3sMA0EP7AMh B+wDIQfsAyEH7AMhB+wDIQfsAyEH7AMhB+wDIQfsAyEH7AMhB+ wDIQfsAyEH7AMhB+wDIQfsAyEH7AMhB+wDIQfsAyEH7AMhB+/Tr398/r9fr9frz91/2Urb8LPXjM3sl53U09upon5v8nLMjZ07hz4/vN4m/pt1qQy6yjfa5YDjXuXDsT0P73MTO2YMX2Pfr/fMn/wjPPOeYQRtEdMBG+5wdznVaxo6jaJ+b/FxgR//BbGmWqPb5vr4+Pk6uefKOW+1T79NEWKFjBu1zk9UL7Pvi/PP3n/8YMP5M4318jv4RnnvO37l/pbdvwfyUz+fCojdWOwr8er0+Pk+0z89jv+8/82ZrH9aGk/GHcEHmvmq2jH12AbOflTbG9Uij6e5++T2HEdDSPlNfzz7aPnbR u6Nuf2/4LZ+FVW+sdmHFy+lbh/P16CTAzHLWCmT9lf4Zre2z8DY/YRrG9VSjgex++T2HEbB6HbgTdHiJ/Z6hx+77TN5nu3yGbzLXC5urHf/3b/Y9931+l+g+/kzXP/ls9PkxXvykJ8brnK70Z6HbY7c3mVbeaDrLm/tUox3f/fJ7DiOgqX3cST4+7Y/edR7Wx97yma2frdXOPH7krvNciQ4v44X1LUWZrGNloT8/2hz73EQ3n8HdpC+jHd/98nsOI6Dpy8UF7TM48P7ymVv41mpXCuvwXedB/6w34exLRjZrcvRhaHnss0sf/JD2WXSyFmifVmnt447cXD4rV2zDaq9on6VbxwfbZ/OzD+1zh9Gu7H75PYcRkNc+v4f+2Drp18qn/Xvi8W9eS+1jN3D+jO+xrN1D2bzGl4PwzesWJ2uB9mkV1D6r3zq WjrH8O+fZ500uitElubna8b3b5rvO8w/749lbTW7YDwpp8KFj2gxLd52X7yAvj33xxn7zuJ7rZC3QPq1Wf wfdcoJOK2T59z/jK8Z/CVksn5UvMcP62V7t3l8yrw5nVABLv5aaO87SOjYe9stsGPv86p u/qD7YaGS7X37PYQSsXghtJ+j4b9Xm6mLh79l+j36kfEb107TaUe H5PyLaNZyVb0e/7zZ8/TDB+L3nP8UM/jZyPvva2EcNNHiI9lk02u7dL7/nMDir7v/LkGj7LjwuRfs8wvR/VwDtk472eQLKZxbtk4z2eQDKZx7tk4z2AZCD9gGQg/YBkIP2AZCD9gGQg/YBkIP2AZCD9gGQg/YBkIP2AZCD9gGQg/YBkIP2AZCD9gGQg/YBkIP2AZCD9gGQg/YBkCOnfQBghPYBkIP2AZCD9gGQg/YBkOOq9gGAWLQPIOLwZ5As3SwUwJLzX4JS9LFKVNDXmf0QsTdi blZ9fUjX6Zn9BFfcCb5T0cV1Mbsn6PfM1tbSO/V3qtyyehncE/R7WmvbWz1ld6rQmrqbnTCBM1vV0vx73KYqC+pxdqp2tA67c6P1 sc/+vPhO5S+Fs7yUpZmzNenWB770UOWdSl5HyzlddnZi1kc9+3N25 07rc155tOw2pS1iZSLTH5Ydn5L1CS89xNbcaWXC61tQc49yFrF +ys7+nLP8artO35WH2JoUm/MvuEEl2qf9UU70LD2e3I/S4/zzv3mtPNTSTb0MunctM2dHEvV4UVRcJSd6QT2e3I/S4wZVXGWPc5THphTX4wZVXGWPc5THphTX4wZVXGWPc5THphTX4 wZVXGWPc5THphTX4wZVXGWPc5THphTX4wZVXGWPc5THphTX4wZ VXGWPc5THphTX4wZVXGWPc5THphTX4wZVXGWPc5THphTX4wZVX GWPc5THphTX4wZVXGWPc5THphTX4wZVXGWPc5THphTX4wZVXGW Pc5THphTX4wZVXGWPc5THphTX4wZVXGWPc5THphTX4wZVXGWPc 5THphTX4wZVXGWPc5THphTX4wZVXGWPc5THphTX4wZVXGWPc5T HphTX4wZVXGWPc5THphTX4wYVXWVfQ3yCHk9uFMdphFZUD2JxJ gHIQfsAyEH7AFd5qTs7H0ZpTo4yS/bYLpc94OOyJ3e5s/NhlObkKLNkj+1y2QM+Lntylzs7H0ZpTo4yS/bYLpc94OOyJ3e5s/NhlObkKLNkj+1y2QM+Lntylzs7H0ZpTo4yS/bYLpc94ONkgpjYRMfb5+SBK9BIpJHCk0kkE8TQPmE0Emmk8GQS yQQxtE8YjUQaKTyZRDJBDO0TRiORRgpPJpFMEEP7hNFIpJHCk0 kkE8TQPmE0Emmk8GQSyQQxtE8YjUQaKTyZRDJBDO0TRiORRgpP JpFMEEP7hNFIpJHCk0kkE8TQPmE0Emmk8GQSyQQxtE8YjUQaKT yZRDJBDO0TRiORRgpPJpFMEEP7hNFIpJHCk0kkE8TQPmE0Emmk 8GQSyQQxtE8YjUQaKTyZRDJBDO0TRiORRgpPJpFMEEP7hNFIpJ HCk0kkE8TQPmE0Emmk8GQSyQQxtE8YjUQaKTyZRDJBDO0TRiOR RgpPJpFMEEP7hNFIpJHCk0kkE8TQPmE0Emmk8GQSyQQxtE8YjU QaKTyZRDJBDO0TRiORRgpPJpFMEEP7hNFIpJHCk0kkE8TQPmE0 Emmk8GQSyQQxtE8YjUQaKTyZRDJBDO0TRiORRgpPJpFMEEP7hN FIpJHCk0kkE8TQPmE0Emmk8GQSyQQxtE8YjUQaKTyZRDJBDO0T RiORRgpPJpFMEEP7hNFIpJHCk0kkE8TQPmE0Emmk8GQSyQQxtE 8YjUQaKTyZRDJBDO0TRiORRgpPJpFMEEP7hNFIpJHCk0kkE8TQ PmE0Emmk8GQSyQQxtE8YjUQaKTyZRDJBDO0TRiORRgpPJpFMEE P7hNFIpJHCk0kkE8TQPmE0Emmk8GQSyQQxtE8YjUQaKbz2RMVT P3lrmt4t68AVaCTSSOE1JqofvP4K96J9wuw9y+9cW7tn7str4u ZFtqi/wr1onzAHzvKbV9ii/gr32kw0rZ6aweuvcC/aJ8yBs/z+RW6qv8K91hP1Uj3v523N7nfLOnAFGmd5/RXutZKol0350ss623XcPv/+/pk5dz4+G57/5++/pUdnHmqkcZZ3schdlhJ1tClfrlvq7KXkr6TzV8es2ES3ts/nx+z5Mx7cj8GEp1O8rn36Ost7WWe72UR9bcqX61a7eCn9XEi0z 9jPyFzVuCmOC+h7fh8f01f5x6Pbp7uz/ORSWz6Qroz6irN8mqi7Tfly3YInl5JdSN8bQfuMzbTP253+w0H 9lM/nwssuaZ8ez/KTq51vn+Fcc9unx035ct2ap9eE7ePXj2ifsYUamf35b/lstVZY+3R6lp9c8HSM9s+ozbta+4Qd6WLXLZv22W2pfWYm9f3U 75/MvvCG9jn4vvc6uebl4Rdtn7DDXO+6lY+36PcT7PdPaJ+x9vYZl s/qp6PL2ufgm97u5LKXP/tM/10t0T79ChvQ8l1n2wbaZ6y5fcblM/vSS9vn4DtmOLny+fs+s/fgbmmflU3pXcyA3u/3fPsEfzOYFZuoRPuMf77ym3k3zXvu+3Rn7xAW7zq3jZr2aRczo Pf7vXwpGdpnbON3Xi3lE/rZ8syZVNbeIcyMcfJbSNonRMyA3u837XPgYKt/77PytWv41IZL4lgiDXuHMDvG0ay57xMibEC0z4GDtfyt88rUFi 6JoT3T3n/+dGDvpvTYPmFHuth1y25un6HTuxSbqNr/57V6Mg+vCdpn1tFNqfLN663yd1hv2mfz3bIOXIHA+f2+7m+dZ+ 46zzx+xVk+TdTpBnW34E2xiWifNdkLbHJyzXv+P6+hG9tn+sMu Nqiv1baITUT7bMhe47buFrxpKVF3G9TRUhvRPmGmibo7v9/P2Jelh4pH7mWd7WifMLOJ+jq/34/Zl6VHK6fuYpG70D5hlhJ1dH6/n7QvS08oG7z+CveifcKsJOrl/H4/bF+WnlMze/HlHUD7hFlP1MX5/X7eviw9rWD8yms7hvYJs5mo/vn9fuS+LD2zWvzKazuG9gnTkqh+AVVe2zG7ElWOX3ltx9A+YRo T0T4325uobHa2ZuPdsg5cQXuiytkrr+0YmUQyQQztE2ZXorLBH 74vlckEMbRPGI1EGik8mUQyQQztE0YjkUYKTyaRTBBD+4TRSKS RwpNJJBPE0D5hNBJppPBkEskEMbRPGI1EGik8mUQyQQztE0Yjk UYKTyaRTBBD+4TRSKSRwpNJJBPE0D5hNBJppPBkEskEMbRPGI1 EGik8mUQyQQztE0YjkUYKTyaRTBBD+4TRSKSRwpNJJBPE0D5hN BJppPBkEskEMbRPGI1EGik8mUQyQQztE0YjkUYKTyaRTBBD+4T RSKSRwpNJJBPE0D5hNBJppPBkEskEMbRPGI1EGik8mUQyQQztE 0YjkUYKTyaRTBBD+4TRSKSRwpNJJBPE0D5hNBJppPBkEskEMbR PGI1EGik8mUQyQQztE0YjkUYKTyaRTBBD+4TRSKSRwpNJJBPE0 D5hNBJppPBkEskEMbRPGI1EGik8mUQyQQztE0YjkUYKTyaRTBB D+4TRSKSRwpNJJBPE0D5hNBJppPBkEskEMbRPGI1EGik8mUQyQ QztE0YjkUYKTyaRTBBD+4TRSKSRwpNJJBPE0D5hNBJppPBkEsk EMbRPGI1EGik8mUQyQQztE0YjkUYKTyaRTBBD+4TRSKSRwpNJJ BPE0D5hNBJppPBkEskEMbRPGI1EGik8mUQyQQztE0YjkUYKTya RTBBD+4TRSKSRwpNJJBPE0D5hNBJppPBkEskEMbRPGI1EGik8m UQyQQztE0YjkUYKTyaRTBBD+4TRSKSRwpNJJBPE0D5hNBJppPB kEskEMbRPGI1EGik8mUQvdWfnwyjNyVFmyR7b5bIHfFz25C53d j6M0pwcZZbssV0ue8DHZU/ucmfnwyjNyVFmyR7b5bIHfFz25C53dj6M0pwcZZbssV0ue8DHZ U/ucmfnwyjNyVFmyR7b5bIHjKuwtQBy0D4ActA+AHLQPgBy0D4Ac tA+AHLQPgBy0D4ActA+AHLQPgBy0D4AcvwHRk+chMMDSB4AAAA ASUVORK5CYII=
البته توی یک مقاله در مورد لایه چهارم یا Application Layer صحبت کرده بود منتها چون شکل نداشت من برام گنگ بود و دقیقا متوجه نشدم منظورش چیه. حالا نمیدانم این شکل که من کشیدم همون منظور را بیان می کنه یا نه.

[cups_of_java]

خب!
ببین یه چیزی رو اول برای خودت راجع به معماری 3tier با 3 سحطی (3 لایه نمی گم) جا بنداز. این معماری به الگوی فیزیکی (برای سطوح اجرا) هستش نه یه لایه در سطح طراحی کد شما! متوجه منظورم میشی؟ یعنی اینکه شما گاهن اصلن کدت جدا از این الگو (و در قالب معماری MVC) شکل میگیره! چرا؟ چون شما ممکنه بخوای یه برنامه MVC رو به جای 3 سطح روی 2 سطح یا 5 سطح پیاده کنی!
اما سوالت کاملن برام روشن شد!
راهی که پیشنهاد دادی یه مشکل بزرگ داره اونم اینه که اون کلاس Entity که تعریف می کنی که هر 3 سطح می بیننش خیلی گنده میشه و آش شوله قلم کار در میاد چون توش همه جور متد خواهد بود!!!
ببین تو ایده آل ترین حالت شما تو لایه P یه کلاس UserForm داری، تو لایه B یه کلاس UserModel داری و تو لایه DA یه کلاس User داری! توجه کن که کلاس UserForm اون قسمتی از اطلاعات و متد ها که مربوط به GUI و اینا میشه رو داره، کلاس UserModel متد هایی داره که می تونه با Userها از طریق کلاس User توی DA کار کنه (خوندن و نوشتن و جستجو و ...) و نهایتن کلاس User توی DA اون متد های سطح پایین مربوط به دیتابیس و اینجور چیزا رو داره! این جوری شما اون زنجیرت درست شکل میگیره! (تو مثالی که زدی مثل این می مونه که شما اون فیلدهاتو بزاری تو یه کلاس جدید که بین P و B تعریف خواهد شد.
یه کم خلاصه توضیح دادم، گرفتی؟
در مورد Exception ها هم همین روال می تونه باشه.
اما اون چیزی که احتیاج داری اصولن با یه الگو به نام Data Transfer Object حل میشه. یه جورایی همون چیزی که هست که تو میخوای.
اگه انگلیسیت ضعیف نیست اینا رو بخون:
http://www.codeproject.com/Articles/493389/Four-ways-of-passing-data-between-layers
http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/

[trustmiracle]

ممنون بابت جواب. یک کمی هنوز سوال دارم. البته بگذارین دو تا لینکی که دادین را سرفرصت بخوانم بعدا اگر رفع نشد می پرسم. البته کلاس های من به این صورت بود:
UserForm برای لایه نمایش
UserModel برای لایه دامنه
UserDaoImpl برای لایه دسترسی داده و در آخر هم کلاس User که مد نظر من هست. کلاس user من با کلاس یوزری که شما گفتین تفاوت داره. من کارهای دیتابیسی مثل خواندن یک یوزر، ویرایش و ... را تو کلاس userDaoImpl انجام میدم. و کلاس یوزری که گفتم فقط یک مدل هست. یک نمونه از یوزر. یعنی فقط داخلش فیلد های یوزر تعریف می شوند با متد های setter , getter. یعنی می خواستم به جای اینکه در هنگام صدا زدن متد های لایه های مختلف متغیرهای رشته ای و ... پاس بدم از یک کلاس یوزر استفاده کنم.
خوب حالا بعد از خواندن لینک هایی که دادین اگر باز موردی برام رفع نشده بود باز مزاحم میشم. ممنون