استفاده از کلاس های Membership و Role در برنامه نویسی 3 لایه

[Payman62]

سلام.
یه سوال در مورد روش به کار گیری کلاس های Membership و Role در برنامه نویسی 3 لایه دارم.

خوب طبیعی هست که تیبل هایی که خودمون ایجاد میکنیم در لایه های برناممون جا میگیرن.

اما در مورد تیبل های مربوط به Membership و Role :
برای مثال در مورد متد CreateUser من میخواستم به صورت سفارشی عمل کنه و پس از ساخت یوزر مقادیر دیگری رو هم در دیتابیس ذخیره کنه.

با توجه به این که کلاس Membership استاتیک هست و امکان ارث بردن ازش و override کردن متد CreateUser وجود نداره من اومدم این متد رو داخل لایه ها قرار دادم و در لایه bll پس از ساخته شدن یوزر درخواست ثبت مقادیر دیگر رو هم به dal فرستادم.

سوال اول این که تا این جای کار اصولی هست یا راه بهتر و اصولی تری وجود داره؟

سوال دوم و سوال اصلیم این که آیا از نظر اصول برنامه نویسی لزومی داره سایر متدهای این کلاس هارو که با دیتابیس در ارتباط هستند ( مثل UpdateUser یا AddUserToRole و ... ) اماقرار نیست سفارشی عمل کنند رو به لایه های برنامه بیارم؟
از این جهت میپرسم که میخوام از پایه سایت رو اصولی طراحی کنم و بعدا به مشکل بر نخورم.
ممنون.

[mmnoody2006]

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

[Payman62]

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

سلام.
این مطلب چه ارتباطی به سوال بنده داشت؟

[Payman62]

سلام.
بنده هم از کلاس membership استفاده میکنم و خیلی هم عالیه. سوالم قرار دادن متدهای این کلاس در لایه های برناممون هست که لازم هست این کار یا نه.

[nasr]

آیا آموزش فارسی در مورد MemberShip وجود نداره؟

[Payman62]

آیا آموزش فارسی در مورد MemberShip وجود نداره؟

سلام.
بله سرچ کنید در همین انجمن مطلب زیاد هست در موردش.

[EnKamran]

چرا خودتون ممبرشیپ درست نمیکنید ؟ والا من حاظرم یه خورده سختی بکشم اما خودم بسازم جداول و استراکچر رو، اسنجوری دستم رو هرچقدر بخوام میتونم باز کنم.

[clover]

با توجه به این که کلاس Membership استاتیک هست و امکان ارث بردن ازش و override کردن متد CreateUser وجود نداره من اومدم این متد رو داخل لایه ها قرار دادم و در لایه bll پس از ساخته شدن یوزر درخواست ثبت مقادیر دیگر رو هم به dal فرستادم.
من هم از همین روش استفاده می کنم و به نظرم روشی منطقی هست. در کل فکر می کنم در صورتی که می خوایید وارد جزییات سیستم ممبرشیپ نشید و در مدل چند لایه از اون استفاده کنید این اولین و ساده ترین راه هست.

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

موفق باشید

[Payman62]

سلام.
ممنون از توضیحاتتون.

سوال بنده این بود که آیا از نظر اصول برنامه نویسی لزومی داره تمام متدهایی از Membership رو که مورد استفاده قرار دادم به داخل لایه های BLL و DAL منتقل کنم؟

[Payman62]

سلام.
من هنوز تو تصمیمم موندم که این توابع رو به لایه ها ببرم یا نه. لطفا نظرتون رو بگید.
یا اگه ایده و روشی به ذهنتون میرسه هم بگید.

[aserfg]

سوال بنده این بود که آیا از نظر اصول برنامه نویسی لزومی داره تمام متدهایی از Membership رو که مورد استفاده قرار دادم به داخل لایه های BLL و DAL منتقل کنم؟
مهمترین اصل برنامه نوسی عدم کدنویسی زائد است ، اصلا لزومی به آوردن کلاسهایی برای map شدن به این جداول نیست . راههای مختلفی برای این کار وجود دارند مثلا برای اطلاعات اضافی که شما فرمودین در CreateUser نیازی نیست این متد رو override کنید بلکه امکان اضافه کردن اطلاعات در پروفایل وجود دارد . (یا در یک جدول جداگانه که از ابتدا خودتوت اون رو در بانک تعریف کردین ) . ابتدا فرمی طراحی کنید که شامل اطلاعات درخواستی شما باشد مانند نام نام خانوادگی ، شماره تلفن ، آدرس و.... (بدون استفاده از کنترل createuserwizard خود asp.net) یک باتن روی فرم گذاشته و رویداد کلیک آن را کدنویسی کنید :
protected void CreateAccountButton_Click(object sender, EventArgs e)
{
MembershipCreateStatus createStatus;
MembershipUser newUser = Membership.CreateUser(Username.Text, Password.Text, Email.Text, passwordQuestion, SecurityAnswer.Text, true, out createStatus);
switch (createStatus)
{
case MembershipCreateStatus.Success:

کدهای شما برای درج اطلاعات اضافی در جدول اضافی تعریف شده یا در پروفایل

{
break;

[Ehsan Boorboor]

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

و وقتی Concept Mapping می کنید یعنی چیز های مفهومی را map می کنید به چیز های حقیقی و واقعی

الان که ما داریم با ASP.NET کار می کنید به ترتیب

لایه نمایش Persentation Layer (در MVC لایه ی View) مپ می شود به فایل های aspx
لایه منطق تجاری BLL (در MVC لایه ی Controler) مپ می شوند به فایل های cs (در واقع همان CodeBehind)
لایه دسترسی به دادها DAL (در MVC لایه ی Model) مپ می شود به کلاس های دسترسی به داده ای که خودتان نوشتید/برنامه ها ی DAL Generator براتون ایجاد کردند/ یا Entity Framework



بنده این بود که آیا از نظر اصول برنامه نویسی لزومی داره تمام متدهایی از Membership رو که مورد استفاده قرار دادم به داخل لایه های BLL و DAL منتقل کنم؟

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

[Ehsan Boorboor]

و در ضمن شما می تونید جداول Users و Roles خودتون رو داشته باشید و با جداولی که خودتان طراحی کردید کار کنید و در عین حال پروسه ی مدیریت کاربران و role ها و membership را به دوش دات نت بگذارید

و به دات نت بگید برای membership با جداول من کار کن

من از این روش ترکیبی استفاده می کنم

و دیگه این مشکل هم وجود نداره که متدهای membership توی کدام لایه قرار بدیم !!!