در کدام لایه بررسی اطلاعات را قبل از ثبت در بانک باید انجام داد؟

سلام دوستان

یک برنامه دارم که مطابق معمول بصورت UnitOfWork دارم با بانک اطاعاتی کار میکنم. یک متد با نام Remove دارم که قبل از حذف یک ردیف باید چند آیتم را بررسی کنه. اول اینکه کاربری که قصد حذف ردیف را دارد همان کاربری باشد که ردیف را ایجاد کرده است و تایید نهایی هم نشده باشد و...

من در متد یکی Pageها دستور را بصورت زیر نوشتم:

        public IActionResult OnPostRemove(int id)

        {

            var report = db.tblDailyReportPiping.Find(id);





            if (report == null)

                return new JsonResult(new { status = false, message = "Invalid Data" });





            //فقط کاربری که اطلاعات را تولید کرده است اجازه حذف اطلاعات را دارد

            if (report.fldUserId != HttpContext.Session.GetActiveUser_UserId())

                return new JsonResult(new { status = false, message = "Incorrect user" });





            //فقط ردیفی را میتاون حذف کرد که تایید اولیه و تایید نهایی نشده باشد

            if (report.fldApproved || report.fldFinalized)

                return new JsonResult(new { status = false, message = "Approved or finalized before" });





            try

            {

                //حذف ردیف مورد نظر

                if (!db.tblDailyReportPiping.Remove(report))

                    return new JsonResult(new { status = false, message = "unable to remove" });





                //ذخیره تغییرات در بانک اطلاعاتی

                if (db.SaveChangesByUserId(HttpContext.Session.GetAct  iveUser_UserId()) == 0)

                    return new JsonResult(new { status = false, message = "unable to save" });

            }

            catch (Exception ex)

            {

                return new JsonResult(new { status = false, message = ex.Message });

            }





            return new JsonResult(true);

        }

سوالم این هستش که ارزیابی یک ردیف جهت حذف یا هر یک از عملیات CRUD در بانک اطلاعاتی در کدام سطح انجام بشه بهتره؟ آیا مثلا در متد بالا فقط دستور Remove را از UOW اجرا کنم و بررسی رو به لایه Repository واگذار کنم؟ یا اینکه در Method ارزیابی را انجام بدم و از لایه Repository صرفا برای ثبت و اعمال تغییرات در بانک استفاده کنم؟

البته خوبی انجام ارزیابی در لایه Repository اینه که اگر برنامه دیگه ای بخواهد ازش استفاده کنه دیگه نگران نحوه حذف اطلاعات نیستم چون قبل از اعمال تغییرات، شرایط حذف توسط Repository بررسی مشه. اما اگر فرض کنیم که استفاده کننده UOW برنامه جاری من باشه، بهترین گزینه کدام است؟ کدهای کدام لایه کمتر باشه بهتره؟ البته فرض دیگر هم اینه که ممکنه دستور Remove از چندجای برنامه صدا زده بشه، بنابراین برای کاهش کدهای تکراری و جلوگیری از خطا به نظرم تمام کدها به لایه Repository انتقال پیدا کنه بهتره. فقط چون آیتم تطبیق کد کاربری باید انجام بشه، ضرورتا باید این مقدار را به لایه Repository ارسال کنم.

ممنون اگر راهنمایی کنید

بهتره که ارزیابی رو همراه با عملیات مورد نظرتون در یک متد باشه تا بعدا اگه خواستید تو یه جای دیگه مثل windows form استفاده کنید به راحتی اینکار و انجام بدید.

سلام. مرسی.

یک موردی که نمیدونم آیا درست هست یا نه اینه که مثلا در برخی موارد نیاز هست تا با HttpContext و یا کلاس های دیگر که فقط در برنامه اصلی در دسترس هستن کار کنم و بعد شاید مقادیری خاصی را هم از این کلاس ها دریافت کنم و به سمت لایه Repository ارسال کنم مثل UserName و یا SessionId.

آیا پیشنهاد میکنید که پارامترهای ورودی را در متدهای لایه Repository اضافه کنم؟ مثلا من برای دستور Remove با توجه به اینکه بررسی میشه کاربر باید همان کاربری باشه که ردیف جاری را تولید کرده، مواردی هست که از طرف مدیر برنامه باید اجبارا Remove انجام بشه. بنابراین متد Remove یک متغیر به نام force و از نوع bool داره که اگر برابر true باشه دیگه تطبق UserId را انجام نمیده و مستقیم دستور Remove انجام میشه. مقدار force از Identity و IsAdmin ارسال میشه در حالی که میشد متغیر force را به متد اضافه نکنم و این بررسی در همان Action انجام بشه. البته بیشتر نگرانیم این هستش که دستور Remove از جاهای مختلف برنامه اجرا بشه و دسترسی به IsAdmin نداشته باشند و بنابراین در نظر گرفتن پارامتر force برای متد الزامی میشه.

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

تشکر

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

سلام

در برنامه من یک پروژه که کلاس های از نوع Interface و یک پروژه دیگه که Interface را پیاده سازی کرده وجود داره. باید لایه دیگه ای اضافه کنم؟ امکانش هست یک نمونه ساده مثال بزنید؟ یا لینک معرفی کنید؟

تشکر

سلام ، این لینک رو ببینید لایه ها رو مختصر توضیح داده و همچنین یه نمونه پروژه هم درست کرده:
https://www.dntips.ir/post/914/%D9%B...-service-layer

سلام مجدد

دوستان اگر تجربه ای در این خصوص دارید لطفا راهنمایی کنید. آیا اصلا ضرورتی داره که کد کاربری در عملیات Remove و Update بررسی بشه که کاربری که قصد حذف ردیف را داره همان کاربری است که آن را تولید کرده؟ البته کاربری که به برنامه ورود کرده قطعا داده های مربوط به خودش را داره مشاهده میکنه و قطعا تغییرات هم روی ردیف های خودش اتفاق میوفته. ولی در بخش هایی از برنامه که مدیر برنامه میتونه فعالیت سایر کاربران رو ببینه میتونه کمی مهم باشه.

تشکر

سلام مجدد

دوستان اگر تجربه ای در این خصوص دارید لطفا راهنمایی کنید. آیا اصلا ضرورتی داره که کد کاربری در عملیات Remove و Update بررسی بشه که کاربری که قصد حذف ردیف را داره همان کاربری است که آن را تولید کرده؟ البته کاربری که به برنامه ورود کرده قطعا داده های مربوط به خودش را داره مشاهده میکنه و قطعا تغییرات هم روی ردیف های خودش اتفاق میوفته. ولی در بخش هایی از برنامه که مدیر برنامه میتونه فعالیت سایر کاربران رو ببینه میتونه کمی مهم باشه.

تشکر

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

سلام

پس از لاگین شدن کاربر به برنامه، اطلاعات مورد نیاز رد session نگهداری میشه. اطلاعات موجود در session هم در برنامه Web در دسترس هست.

سوالم اینه که اگر بخوام لایه سرویس اضافه کنم آیا باید پروژه جداگانه ای ایجاد کنم؟ اگر بله؛ پس باید اطلاعات session و یا cookie را برای اون پروژه هم ارسال کنم. پس چه ایرادی داره که همین مقادیر را به عنوان پارامتر برای متدها ارسال کنم و دیگه لایه سرویس ایجاد نکنم.

البته مورد بالا را به این خاطر عنوان کردم که با توجه به مرور نمونه کارها در اینترنت و لینکی که معرفی کردید، دقیق متوجه نمیشم که لایه سرویس به چه صورت پیاده سازی شده. می خواستم اگر براتون امکان داره ساختار ارتباط این لایه ها را بدون کدهای پیاده سازی و فقط عنوان کلاس ها در پست بعدی ارسال کنید. ممنون میشم. البته برنامه من از یک پروژه شامل کلاس های interface و یک پروژه دیگر شامل کلاس هایی که پیاده سازی لایه interface هستش و خود برنامه web تشکیل شده که در services کلاس context را inject کردم.

تشکر

سلام ببینید هدف از لایه بندی نرم افزار جدا سازی وظایف از همدیگه هست که توسعه نرم افزار در آینده راحتتر صورت بگیره، شما می تونید اعتبار سنجی توی لایه دیتا انجام بدید منتهی اینجا یه مشکلی وجود داره ، اگه احیانا در آینده خواستید دیتابیستون رو عوض کنید اونوقت باید لایه دیتا رو دوباره بازنویسی کنید چرا به خاطر اینکه علاوه بر عملیات دیتابیسی شما اومدید کارهای دیگه مثل اعتبار سنجی هم اینجا انجام دادید، لذا هر عملی رو در لایه ی مختص به خودش انجام بدید. بدتر از همه اون موقعی که می خواهید orm پروژه رو عوض کنید مثلا الان از ef استفاده می کنید حالا می خواهید تغییرش بدید به nhibernate. یا dapper.

سلام و تشکر

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

در Solution تعدادی پروژه تعریف کردم که با معرفی هر کدام، کدهای هر بخش را هم جهت رفع ابهام قرار میدم.

پروژه cesEntities: این پروژه شامل کلاس های Entity هستش:

    public partial class tblCompany

    {

        [Key]

        public int fldId { get; set; }

        public string fldNameLan1 { get; set; }

        public string fldNameLan2 { get; set; }

        public string fldCode { get; set; }

        public string fldTel { get; set; }

        public string fldFax { get; set; }

        public string fldEmail { get; set; }

    }

پروژه cesIRepository: شامل کلاس های Interface جهت تعریف متدهای مورد نظر می باشد:

    public interface ICompany : IBaseMethods<cesEntities.Models.cesProject.tblComp  any>

    {

    }

کلاس ICompany از IBaseMethods ارث بری کرده که این کلاس هم فهرست متدهای مشترک هستش که هر کلاس اون رو ارث بری کنه می بایست متدهای اون رو پیاده سازی کنه که شامل متدهای Add, Remove و ... میباشد.

در همین پروژه IUnitOfWork هم بصورت زیر تعریف شده:

    public partial interface IUnitOfWork

    {

        public cesProject.ICompany tblCompany { get; }

    }

پروژه cesRepository: این پروژه شامل کلاس هایی هستش که تمام متدهای کلاس های Interface متناظر در IRepository را پیاده سازی کرده:

    public class tblCompany : cesIRepositories.cesProject.ICompany

    {

        private cesContexts.cesContext db;





        public tblCompany(cesContexts.cesContext context)

        {

            db = context;

        }





        public bool Add(cesEntities.Models.cesProject.tblCompany model)

        {

            if (!db.tblCompany.Any(c => c.fldNameLan1 == model.fldNameLan1))

            {

                db.tblCompany.Add(model);

                return true;

            }

            return false;

        }

    }

در زمان نمونه سازی از کلاسهای موجود در Repository باید context مورد نظر به عنوان پارامتر مقداردهی شود. همچنین کلاس UnitOfWork در پروژه cesRepository بصورت زیر پیاده سازی شده:

    public sealed class UnitOfWork : IUnitOfWork

    {

        private readonly cesContexts.cesContext db;





        public UnitOfWork(cesContexts.cesContext context)

        {

            db = context;

        }





        private readonly cesProject.tblCompany _tblCompany;

        public ICompany tblCompany => _tblCompany ?? new cesProject.tblCompany(db);

    }

پروژه Asp.NET Core: این پروژه استفاده کننده از context هستش و در service برنامه بصورت زیر تزریق شده است:

builder.Services.AddDbContext<cesContexts.cesConte  xt>(options =>

{

    options.UseSqlServer(builder.Configuration.GetConn  ectionString("DefaultConnection"));

});



builder.Services.AddTransient<cesIRepositories.IUn  itOfWork, cesRepositories.UnitOfWork>();

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

سلام ، شما کاری که باید بکنید اینه یه لایه به نام service ایجاد کنید و داخل کلاسهای سرویس از unit of work استفاده کنید و دیگه تو کنترلرهاتون صداش نزیند و به جای اون سرویس مورد نظر را صدا بزنید و به عبارتی سرویس باید ما بین کنترلر و unit of work (لایه داده) باشه.

سلام

سوالی که برام پیش اومده این هستش که در لایه سرویس میتونم برای پیاده سازی متدها، از همان پروژه interface که متدها رو تعریف کردم مجددا استفاده کنم؟ پروژه interface یکبار در پروژه Repository هم استفاده شده.اگر اینطور بشه دیگه در لایه Repository که متدها پیاده سازی شده اند دیگه نیازی به بررسی اطلاعات وجود نداره؟ آیا فقط دستورات ساده CRUD کفایت میکنه؟

سوال جدید که به ذهنم رسیده:

اگر قرار باشه تمام logic برنامه در service انجام بشه و در انتها یک Model به لایه Data ارسال کنیم آیا میشه تنها یک پروژه Interface جهت استفاده در service ایجاد کنیم و لایه Data بصورت Generic و پروژه بسیار کوچکی باشه؟

نقل قول:

---

نوشته شده توسط mmbguide

سوال جدید که به ذهنم رسیده:

اگر قرار باشه تمام logic برنامه در service انجام بشه و در انتها یک Model به لایه Data ارسال کنیم آیا میشه تنها یک پروژه Interface جهت استفاده در service ایجاد کنیم و لایه Data بصورت Generic و پروژه بسیار کوچکی باشه؟

---

سلام ،بله درسته، لایه data هم بنا به نیازتون طراحی کنید.