LINQ to SQL یا .... جهت استفاده از دیتابیس و مشکلات هر یک

سلام دوستان.
راستش بنده تا حالا هر چی خواستم از دیتابیس توی برنامه هام استفاده کنم از لینکیو استفاده میکردم و معمولا برای عملیات اصلی روی جداول پروسیجرهایی مینوشتم و اونها رو در موقع خودش توی C#‎ صدا میزدم یعنی از طریق Linq To DataClasses (اگه اسمشو درست نوشته باشم!).
نمیدونم این راه تا چه حد درسته یا اصلا اشتباهه یا نه ولی الان این سوال برام پیش اومده که من اگه نرم افزار روی کلاینت ها نصب شده باشه و در حال کار باشه و بخوام یکی از این پروسیجرها رو تغییر بدم ظاهرا باید اول پروسیجر رو توی دیتابیس تغییر بدم بعد پروسیجر رو مجددا توی Linq To classes لود کنم بعد مجددا برنامه تست بشه ستاپ ساخته بشه و مجدد روی کلاینت ها نصب بشه ...!!
به نظرم اصلا منطقی نیس :لبخندساده:
1. بنظرتون باید چکار کرد؟
2.. آیا این راه استفاده از لینکیو (Linq To Classes) خوبه یا باید از راه های دیگه(که بنده بلد نیستم!)استفاده کنیم؟
ممنون

Linq To Classes جای خودش رو داده به Ling to Entity و کم کم مثل دیتاست ها داره منسوخ میشه
در ضمن زمانیکه شما یک سرور کلاینت راه اندازی میکنید سرویس ها و دستورات اسکیول باید توی سرور نوشته شده و پیاده سازی بشن و فقط از سمت کلاینت فراخوانی بشن و نیازی نیست توی سیستم کلاینت دستور اسکیولی بنویسید

سلام. شما باید اگه پروسیجرهارو تغییر بدید در صورتی که خروجی و ورودی ها تغییر کند باید نرم افزارهم بروزرسانی کنید.

نقل قول:

---

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

Linq To Classes جای خودش رو داده به Ling to Entity و کم کم مثل دیتاست ها داره منسوخ میشه
در ضمن زمانیکه شما یک سرور کلاینت راه اندازی میکنید سرویس ها و دستورات اسکیول باید توی سرور نوشته شده و پیاده سازی بشن و فقط از سمت کلاینت فراخوانی بشن و نیازی نیست توی سیستم کلاینت دستور اسکیولی بنویسید

---

ممنون.
1.مزیت های Ling to Entity نسبت به Linq To classes چی هستش؟آموزشی ازش دارین؟
2.دستوراتی مثل درج و حذف و ویرایش روی جداول همونطور که گفتم از طریق پروسیجرهایی که توی sql server نوشته شده اند انجام میگیره بعد اون ها رو توی linq to classes توی C#‎ اضافه میکردم و توی برنامه صداشون میکردم.حالا مشکل اینجاست که وقتی نرم افزار پیاده سازی میشه اگه یه تغییر ساده بخوام توی یکی از پروسیجرها بدم باید بعد از اینکه تغییر توی پروسیجر داده شد دوباره اون رو توی Linq to classes بیارم و مجددا از برنامه ستاپ بسازم و مجددا نسخه جدید نرم افزار رو روی کلاینت ها نصب کنم.یه مقدار این روش بنظرم غیر منطقیه که برای یه تغییر کوچیک توی پروسیجر باید این کارها رو بکنم.نمیدونم متوجه منظورم شدین؟
یه مقدار توضیح میدین؟

بهترین راه ممکن بکارگیری EF Code First هست به همرا ه الگوهای محبوبی مثل MVC برای وب و MVVM برای WPF
و تمام نیازمندی های یک برنامه ماژولار رو بر طرف میکنه و دست و پاگیری هم نداره و به راحتی میتونید برای برنامتون plugins تهیه کنید و بدید به کاربرتون
بگار گیری sP های سمت اسکیول سرور با رفلکشن سمت کدنویسی C#‎ منافات خوبی نداره
در روش Code First نیازی نیست ابتدا sp ها رو توی اسکیول بسازید و تخت C#‎ فراخوانی بکنید خودتون ابتدا sp ها رو توی سی شارپ و از طریق EF بنویسید و با عملیات migration اونو بفرستید سمت اسکیول سرور و توی دیتابیس ذخیره کنید

نقل قول:

---

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

بهترین راه ممکن بکارگیری EF Code First هست به همرا ه الگوهای محبوبی مثل MVC برای وب و MVVM برای WPF
و تمام نیازمندی های یک برنامه ماژولار رو بر طرف میکنه و دست و پاگیری هم نداره و به راحتی میتونید برای برنامتون plugins تهیه کنید و بدید به کاربرتون
بگار گیری sP های سمت اسکیول سرور با رفلکشن سمت کدنویسی C#‎‎ منافات خوبی نداره
در روش Code First نیازی نیست ابتدا sp ها رو توی اسکیول بسازید و تخت C#‎‎ فراخوانی بکنید خودتون ابتدا sp ها رو توی سی شارپ و از طریق EF بنویسید و با عملیات migration اونو بفرستید سمت اسکیول سرور و توی دیتابیس ذخیره کنید

---

ممنون دوست عزیز ولی بحث فرق کرد.تا قبل شما بحث Linq To Classes و Linq To Entity بود.نظرتون در مورد این دو تا چیه؟
ضمن اینکه EF Code First توی برنامه های Windows application قابل استفاده هست؟
ممنون

ببین دوست عزیز .. شما باید با توجه به نیازتون تکنولوژی ارتباط با پایگاه داده رو انتخاب کنید .
ما تکنولوژی های مختلفی برای ارتباط با پایگاه داده تو دات نت داریم :
Linq , EF , ADO , NHibernate و ...
لینک برای خودش دنیایی داره که به سه دسته Linq To Sql , Linq To Object , Linq To XML تقسیم میشه ... !
همونطوری که میدونیم استفاده از EF و Linq تفاوت چندانی با هم نداره .. مهم تبدیل کدهای شما چه از Linq Expressionچه از Lambda Expression به کدهای sql هستش که هرکدوم EF یا Linq در مواردی کوئری های بهینه تری نسبت به همدیگه تولید میکنن و نمیشه گفت کدوم بهتره چون عملکرد جفتشون خوب و قابل قبول هستش ولی در مواردی نسبت به همدیگه برتری دارن ... .
مزیت ORM های Linq و EF این هستش که سرعت توسعه شما رو بالا میبره به علاوه شما وقتی EF Code First کار میکنید دیگه عملا درگیر Sql Server نمیشید .
مزیت ADO و نوشتن SP داخل SQL Server این هستش که سرعت اجرای بیشتری بهتون میده ...
همونطوری که میدونیم SQL Server میاد برای کوئری ها نقشه اجرا درست میکنه .. شما وقتی داخل پایگاه داده SP بنویسید پلن این اس پی , کش میشه و دیگه سری بعدی از پلن کش شده استفاده میکنه مثلا شما وقتی از یک جدول سلکت میزنی برای n بار فقط یکبار پلن براش کشیده میشه ولی EF و Linq هر سری یه پلن باید براشون درست شه که خود این میتونه یه دلیل برای کم بودن سرعت ORM ها باشه ... البته از طریق ORM ها میشه SP فراخوانی کرد ولی خب عملا دیگه فرقی نمیکنه که شما ORM استفاده کنید یا نه چون کار اصلیشو ازش گرفتیم و داریم SP مینویسیم و فقط Map کردن کلاس ها میمونه که همونم میتونیم خودمون بنویسیم .
به علاوه شما وقتی SP مینویسی میتونی از امکانات جدید SQL Server 2016 هم استفاده کنی مثل Native Compile Stored Procedure که سرعت بیشتری به شما میده نسبت به SP های معمولی .. .
نکته مهم اینجاست .. دوتا از شاهکارهای Sql Server 2016 اینا هستش : live execution plans , column store index که البته column store index تو نسخه های قبلی بوده ولی بهبود های چشمگیری داشته که اینجا جایی برای توضیح نداره .. شما وقتی Code First کار کنید دیگه نمیتونید از یکی از بزرگترین شاهکارهای SQl Server به اسم column store index استفاده کنید و همینطور چون کوئریهارو ORM مینویسه شما live execution plans ندارید .. مگر این که پروفایل کنید دیتابیسو و کوئریهارو استخراج کنید و تو اس کیو ال سرور بنویسید و اجرا بگیرید که دیگه اینطوری ORM برای برنامه نویس که شما باشید تا حدی هرچند کم میره زیر سوال چون کوئری هارو دوباره دارید بازنویسی میکنید و هر تغییری یعنی راه دوباره .

خب بخوام نتیجه گیری کنم با توجه به تجربه چندین ساله خودم عرض میکنم ..
1 - زمانی که سرعت توسعه مهمه و پروژه کوچیک در حد سیستم مالی یه فروشگاه یا همچین چیزی باشه EF Code First رو انتخاب میکنم .
2 - اگه طراحی پایگاه داده مهم باشه برام و سرعت توسعه هم مهم باشه EF Database First .
3 - اگه فورس زمانی داشته باشم و سرعت تراکنش های پایگاه داده هم مهم باشه اول کار مشتری رو با EF Database First .
4 - اگر روی کلان سیستم ها و پروژه های ملی باشم بدون هیچ شکو تردید ADO و SP سمت پایگاه داده , زمان توسعه کم میشه ولی من زمان رو قربانی یه کار پر سرعت و با کیفیت میکنم (به علاوع میتونیم قدرت مانور بیشتری برای توسعه نیز داشته باشیم با این روش (سایتی مثل StackOverFlow هم همینکارو کرده و از امکانات جدید Sql Server 2014 استفاده , الان داره با حداقل ریسورس های سخت افزاری بیشترین بهروری رو میده) ) .

نقل قول:

---

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

ببین دوست عزیز .. شما باید با توجه به نیازتون تکنولوژی ارتباط با پایگاه داده رو انتخاب کنید . ما تکنولوژی های مختلفی برای ارتباط با پایگاه داده تو دات نت داریم : Linq , EF , ADO , NHibernate و ... لینک برای خودش دنیایی داره که به سه دسته Linq To Sql , Linq To Object , Linq To XML تقسیم میشه ... ! همونطوری که میدونیم استفاده از EF و Linq تفاوت چندانی با هم نداره .. مهم تبدیل کدهای شما چه از Linq Expressionچه از Lambda Expression به کدهای sql هستش که هرکدوم EF یا Linq در مواردی کوئری های بهینه تری نسبت به همدیگه تولید میکنن و نمیشه گفت کدوم بهتره چون عملکرد جفتشون خوب و قابل قبول هستش ولی در مواردی نسبت به همدیگه برتری دارن ... . مزیت ORM های Linq و EF این هستش که سرعت توسعه شما رو بالا میبره به علاوه شما وقتی EF Code First کار میکنید دیگه عملا درگیر Sql Server نمیشید . مزیت ADO و نوشتن SP داخل SQL Server این هستش که سرعت اجرای بیشتری بهتون میده ... همونطوری که میدونیم SQL Server میاد برای کوئری ها نقشه اجرا درست میکنه .. شما وقتی داخل پایگاه داده SP بنویسید پلن این اس پی , کش میشه و دیگه سری بعدی از پلن کش شده استفاده میکنه مثلا شما وقتی از یک جدول سلکت میزنی برای n بار فقط یکبار پلن براش کشیده میشه ولی EF و Linq هر سری یه پلن باید براشون درست شه که خود این میتونه یه دلیل برای کم بودن سرعت ORM ها باشه ... البته از طریق ORM ها میشه SP فراخوانی کرد ولی خب عملا دیگه فرقی نمیکنه که شما ORM استفاده کنید یا نه چون کار اصلیشو ازش گرفتیم و داریم SP مینویسیم و فقط Map کردن کلاس ها میمونه که همونم میتونیم خودمون بنویسیم . به علاوه شما وقتی SP مینویسی میتونی از امکانات جدید SQL Server 2016 هم استفاده کنی مثل Native Compile Stored Procedure که سرعت بیشتری به شما میده نسبت به SP های معمولی .. . نکته مهم اینجاست .. دوتا از شاهکارهای Sql Server 2016 اینا هستش : live execution plans , column store index که البته column store index تو نسخه های قبلی بوده ولی بهبود های چشمگیری داشته که اینجا جایی برای توضیح نداره .. شما وقتی Code First کار کنید دیگه نمیتونید از یکی از بزرگترین شاهکارهای SQl Server به اسم column store index استفاده کنید و همینطور چون کوئریهارو ORM مینویسه شما live execution plans ندارید .. مگر این که پروفایل کنید دیتابیسو و کوئریهارو استخراج کنید و تو اس کیو ال سرور بنویسید و اجرا بگیرید که دیگه اینطوری ORM برای برنامه نویس که شما باشید تا حدی هرچند کم میره زیر سوال چون کوئری هارو دوباره دارید بازنویسی میکنید و هر تغییری یعنی راه دوباره . خب بخوام نتیجه گیری کنم با توجه به تجربه چندین ساله خودم عرض میکنم .. 1 - زمانی که سرعت توسعه مهمه و پروژه کوچیک در حد سیستم مالی یه فروشگاه یا همچین چیزی باشه EF Code First رو انتخاب میکنم . 2 - اگه طراحی پایگاه داده مهم باشه برام و سرعت توسعه هم مهم باشه EF Database First . 3 - اگه فورس زمانی داشته باشم و سرعت تراکنش های پایگاه داده هم مهم باشه اول کار مشتری رو با EF Database First . 4 - اگر روی کلان سیستم ها و پروژه های ملی باشم بدون هیچ شکو تردید ADO و SP سمت پایگاه داده , زمان توسعه کم میشه ولی من زمان رو قربانی یه کار پر سرعت و با کیفیت میکنم (به علاوع میتونیم قدرت مانور بیشتری برای توسعه نیز داشته باشیم با این روش (سایتی مثل StackOverFlow هم همینکارو کرده و از امکانات جدید Sql Server 2014 استفاده , الان داره با حداقل ریسورس های سخت افزاری بیشترین بهروری رو میده) ) .

---

ممنون.چند تایی سوال: 1.ORM چیه؟ 2. شما میفرمایید که وقتی SP داخل SQL Server نوشته بشه بهتره چون یکبار plan براش ایجاد میشه و سرعتش بیشتره ولی EFو Linq هر سری یه plan برا sp ها ایجاد میکنه و باعث کندی میشه.خب؟ حالا سوال من اینکه مگه به غیر از Linq (که ما میومدیم sp رو توی Linq to classes درگ میکردیم)چه راه دیگه ای هست که بشه از sp های نوشته شده توی sql server استفاده کرد؟ ممنون

تشکر از پاسخ تون عالی بود – چند تا سوال برام پیش اومده؟
1-آیا راهی برای تبدیل کوئری های نوشته شده از قبل SQLServer به EF یا Linq موجود هست؟ نرم افزاری و...

2-آیا برای این رفرنسی دارید که Linq,EF نمیشه از قابلیت های زیر که در SQLServer 2016 فرمودید سود برد؟

[نکته مهم اینجاست .. دوتا از شاهکارهای Sql Server 2016 اینا هستش : live execution plans , column store index که البته column store index تو نسخه های قبلی بوده ولی بهبود های چشمگیری داشته که اینجا جایی برای توضیح نداره .. شما وقتی Code First کار کنید دیگه نمیتونید از یکی از بزرگترین شاهکارهای SQl Server به اسم column store index استفاده کنید و همینطور چون کوئریهارو ORM مینویسه شما live execution plans ندارید .. مگر این که پروفایل کنید دیتابیسو و کوئریهارو استخراج کنید و تو اس کیو ال سرور بنویسید و اجرا بگیرید که دیگه اینطوری ORM برای برنامه نویس که شما باشید تا حدی هرچند کم میره زیر سوال چون کوئری هارو دوباره دارید بازنویسی میکنید و هر تغییری یعنی راه دوباره .]

3-آیا T-SQL نسبت به EF یا LINQ ضعف دار تر هست؟ وآیا امنیتش پایین هست؟ برای یکی برنامه ای طراحی کردم با T-SQL و قابلیت های SQLServer در برنامه ام سود بردم ولی میگه حتما با EF , Linq باشه دبه درآورد و هزینه را نمیده

ORM یه لایه ایه بین بانک اطلاعاتی و کدهای سی شارپ شما .. درواقع میاد اینو تبدیل میکنه به این :
این یک کوئری به زبان لینک هستش (فرض میکنیم یک ابجکت معادل با یک جدول بانک اطلاعاتی داریم که لیستی از کاربران را با مقادیر نام , نام خانوادی و سن دارد)

var result = from c in Users where c.Age > 10 select c;

این هم کوئری بالایی به روش لامبدا (که معمولا برای EF از این استفاده میکنن)

var result = Users.where(c => c.Age > 10);

البته در لامیدا کوئری دستور where به صورت defer loading اجرا میشه .. بهتره که این شکلی نوشته بشه

var result = Users.where(c => c.Age > 10).ToList();

حالا ORM میاد کوئری های شما رو با استاندارد های SQL حالا چه T-Sql چه Pl-Sql و ... به دستورات قابل فهم بانک اطلاعاتی تبدیل میکنه که مثلا T-Sql به این شکل میشه :

select [Name],[Family],[Age] from Users where [Age] > 10

نقل قول:

---

الا سوال من اینکه مگه به غیر از Linq (که ما میومدیم sp رو توی Linq to classes درگ میکردیم)چه راه دیگه ای هست که بشه از sp های نوشته شده توی sql server استفاده کرد؟

---

بله .. n تا روش وجود داره ... مثلا به روش ADO :

SqlConnection sqlConnection1 = new SqlConnection("Your Connection String");SqlCommand cmd = new SqlCommand();

SqlDataReader reader;



cmd.CommandText = "StoredProcedureName";

cmd.CommandType = CommandType.StoredProcedure;

cmd.Connection = sqlConnection1;



sqlConnection1.Open();



reader = cmd.ExecuteReader();

// Data is accessible through the DataReader object here.

 sqlConnection1.Close();

نقل قول:

---

1-آیا راهی برای تبدیل کوئری های نوشته شده از قبل SQLServer به EF یا Linq موجود هست؟ نرم افزاری و...

---

کافیه تو گوگل convert sql query to linq tools را سرچ کنید .. فک کنم این به کارتون بیادhttps://www.linqpad.net/

نقل قول:

---

آیا برای این رفرنسی دارید که Linq,EF نمیشه از قابلیت های زیر که در SQLServer 2016 فرمودید سود برد؟

---

شما دو تا راه برای مشخص کردن ساختار بانک اطلاعاتی در EF Code First دارید , 1 - Data Annotations و 2 - FluentApi .. فئونت از انوتیشن ها قوی تره و دست شمارو باز میزاره .. ولی با این حال در طراحی تنظیمات اپتدایی به شما میده .. اصلا فلسفه به وجود اومدن EF توسط ماکروسافت تو یه جمله خلاصه شد : برنامه نویس برنامه نویسه نباید درگیره پایگاه داده بشه .. شما اگر انوتیشن ها و فئونت ها رو رو هم بررسی کنید کاملا برات ملموس میشه که خیلی خیلی محدودتر از امکانات طراحی SSMS هستش .. خصوصا امکانات پیشرفته ای مثل Column Store .. ولی میگم با پروفایل کردن بانک باز میشه با یکمی وقت گذاشت و کدهای ORM رو دراوردن اجراشون کرد و Live Plan رو دید .
البته 28 روز پیش نسخه بتا 6.2 EF اومده که باید بررسی بشه ولی خیلی خیلی بعیده که همچین چیزایی تو طراحیش بیاد چون مربوطه به DBA . با این حال شما میتونی تو SSMS بانک ساخته شده توسط EF رو باز کنید و تغییرات رو دستی بهش بدین ولی بعدش دیگه نباید بگین که من از EF Code First استفاده میکنم .. . درمورد منبع هم باید بگم چیزی که عیان است چه حاجت به بیات است ؟ این مستند EF چیزی توش پیدا کردین راجب این موضوع مارو بی خبر نزارید http://www.entityframeworktutorial.net :چشمک:

نقل قول:

---

-آیا T-SQL نسبت به EF یا LINQ ضعف دار تر هست؟ وآیا امنیتش پایین هست؟ برای یکی برنامه ای طراحی کردم با T-SQL و قابلیت های SQLServer در برنامه ام سود بردم ولی میگه حتما با EF , Linq باشه دبه درآورد و هزینه را نمیده

---

دستورات شما در نهایت توسط او ار.ام های Linq یا EF به T-Sql تبدیل میشه ...

CsharpNevisi عزیز ممنون بابت توضیحات دقیق و واضحتون.
ولی یه سوال هستش که هنوز من به جواب نرسیدم:
بهتره اینطور توضیح بدم:فرض کنید شما توی کدای C#‎ با استفاده از کد زیر(Linq یا lambda بودنش فرقی نداره) داده ها رو توی یه گرید نشون میدید:

var result = from c in Users where c.Age > 10 select c;

شما دیتابیس رو روی سرور قرار دادین برنام هم روی کلاینت ها نصب میشه.
بعد از چند روز بهتون اعلام میشه "نه ما لیست کاربرای بالای 15 سال رو میخوایم":لبخندساده:
زیاد جالب نیست که به خاطر یه تغییر به این کوچکی بخوایم بعد از تغییر توی سورس مجددا نرم افزار رو برای تک تک کلاینت ها نصب کنیم.
من فکر میکردم اگه همین کوئری بالا رو بیام با زبان TSql توی یه sp در دیتابیس بنویسم و این sp رو توی Linq to classes بیارم و توی کدهام صداش بزنم دیگه با یه تغییر توی sp روی سرور نیازی به نصب مجدد نرم افزار نیست که بعد فهمیدم نه فکرم اشتباه بوده چرا که بعد از اینکه sp رو تغییر میدم باید مجدد اون رو توی linq to classes درگ کنم (تا یه جورایی refresh بشه)و مجددا نرم افزار برای تک تک کلاینت ها نصب بشه و...
بنظر شما باید چکار کرد که نخواین بخاطر یه تغییر به این کوچیکی مجددا نرم افزار رو برای تک تک کلاینت ها نصب کنیم؟
ممنون

نقل قول:

---

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

CsharpNevisi عزیز ممنون بابت توضیحات دقیق و واضحتون.
ولی یه سوال هستش که هنوز من به جواب نرسیدم:
بهتره اینطور توضیح بدم:فرض کنید شما توی کدای C#‎‎ با استفاده از کد زیر(Linq یا lambda بودنش فرقی نداره) داده ها رو توی یه گرید نشون میدید:

var result = from c in Users where c.Age > 10 select c;

شما دیتابیس رو روی سرور قرار دادین برنام هم روی کلاینت ها نصب میشه.
بعد از چند روز بهتون اعلام میشه "نه ما لیست کاربرای بالای 15 سال رو میخوایم":لبخندساده:
زیاد جالب نیست که به خاطر یه تغییر به این کوچکی بخوایم بعد از تغییر توی سورس مجددا نرم افزار رو برای تک تک کلاینت ها نصب کنیم.
من فکر میکردم اگه همین کوئری بالا رو بیام با زبان TSql توی یه sp در دیتابیس بنویسم و این sp رو توی Linq to classes بیارم و توی کدهام صداش بزنم دیگه با یه تغییر توی sp روی سرور نیازی به نصب مجدد نرم افزار نیست که بعد فهمیدم نه فکرم اشتباه بوده چرا که بعد از اینکه sp رو تغییر میدم باید مجدد اون رو توی linq to classes درگ کنم (تا یه جورایی refresh بشه)و مجددا نرم افزار برای تک تک کلاینت ها نصب بشه و...
بنظر شما باید چکار کرد که نخواین بخاطر یه تغییر به این کوچیکی مجددا نرم افزار رو برای تک تک کلاینت ها نصب کنیم؟
ممنون

---

ببینید ... وقتی شما SP رو داخل DatabaseContext لینک درگ میکنید ... براش یک کلاس ایجاد میشه و تا زمانی که ساختار خروجی SP تغییر نکنه نیازی به درگ برای اجرا ندارید ... ولی اگه مثلا دو ستون بازگشتی بشه سه ستون بازگشتی دیگه مجبوری که یه اپدیت واسه برنامه بدی ...
یه چیزی هست .. الان دیگه میگن کار درستی نیست که بیزینس برنامه بره تو دیتابیس .. ولی شما یه جاهایی نیاز داری که این کارو بکنی و نمیشه کاریش کرد ..
اگه من جای شما باشم تو این مورد میام از معماری میکرو سرویس استفاده میکنم ... یا حداقل یه وب سرویس مینویسم که لایه ای بین برنامه آفلاین و دیتابیس بانک تو سرور باشه و به هیچ عنوان از کلاینت مستقیم به سرور وصل نمیشم .. اگه برنامه ممکنه تو طول زمان تغییرات زیادی داشته باشه و مدلا ممکنه تغییر کنه میام یه همچیو جنرال مینویسم که مثلا ساختار مدلارو از WSDL وبسرویس میگیره .. مدلارو ران تایم میسازه و از خود وبسرویس به عنوان لایه ارتباط با پایگاه داده و استفاده میکنم که خود وبسرویس هم میتونه پشت خودش لاجیک داشته باشه (اگه برنامه نویسی وب بلد نیست و یا با معماری های تحت وب آشنا نیستین براتون خیلی سخت میشه که سمت این راه حل برین ولی راه حل کاملا اصولی و منطقی هستش .. بخصوص معماری میکرو سرویس که تو فریم ورک .Ner Core ماکروسافت هم جا باز کرده) .
اگر مشکل شما در حد تغییر بیزینس هستش مثل همین شرط where و نمیخوایید درگیر وب بشید .. شما یا باید شرط هارو از کاربر بگیرید مثلا همین سالو کاربر فیلتر کنه .. یا همه ی لاجیک برنامه رو ببرید تو SP (که البته میگن این کارو نکنید , چون شما مستقیمم به بانک وصل میشید داستان میشه :لبخند:) .
شما میتونید یه سیستمی بنویسید که نرم افزار خود به خود خودشو آپدیت کنه .. یعنی وقتی نرم افزار باز شد رو سرور نسخه رو با نسخه خودش چک کنه و خودشو آپدیت کنه چون نرم افزار شما از بانک آنلاین استفاده میکنه پس همیشه باید آنلاین باشه .. فکر کنم این راه برای شما ساده تر باشه

راستی lambda یه قسمتی از Linq هستش که به صورت متد الحاقی برای لیست ها , آرایه ها و ... پیاده سازی شده .

نقل قول:

---

تا زمانی که ساختار خروجی SP تغییر نکنه نیازی به درگ برای اجرا ندارید ...

---

مطمئنید؟؟؟یعنی من اگه توی sp(سمت سرور)شرط رو عوض کنم نیازی به درگ و ورژن جدید نیست؟

نقل قول:

---

الان دیگه میگن کار درستی نیست که بیزینس برنامه بره تو دیتابیس ..

---

چرا؟ من تمام عملیات درج،حذف و ویرایش روی جداول رو از طریق sp انجام میدم!

نقل قول:

---

گر مشکل شما در حد تغییر بیزینس هستش مثل همین شرط where و نمیخوایید درگیر وب بشید .. شما یا باید شرط هارو از کاربر بگیرید

---

نه همیشه شرط نیست مثال زدم.گاهی وقتا مثلا ممکنه بعد ها بفهمی مثلا توی یه sp یه فرمولی رو اشتباه نوشتی!(که واویلاس برا داده های قبلی!)

نقل قول:

---

یا همه ی لاجیک برنامه رو ببرید تو SP (که البته میگن این کارو نکنید , چون شما مستقیمم به بانک وصل میشید داستان میشه :لبخند:) .

---

منظورتون همین کاریه که من میکردم(درج ،حذف ویرایش؟)؟
منظورتون از مستقیم چیه؟چه داستانی؟اتصال به سرور از طریق connection string توی کدها اتفاق میافته و کاربر هیچ اطلاعی از اون نداره.

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

نقل قول:

---

الان دیگه میگن کار درستی نیست که بیزینس برنامه بره تو دیتابیس

---

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

نقل قول:

---

مطمئنید؟؟؟یعنی من اگه توی sp(سمت سرور)شرط رو عوض کنم نیازی به درگ و ورژن جدید نیست؟

---

بله .

نقل قول:

---

چرا؟ من تمام عملیات درج،حذف و ویرایش روی جداول رو از طریق sp انجام میدم!

---

نقل قول:

---

منظورتون همین کاریه که من میکردم(درج ،حذف ویرایش؟)؟
منظورتون از مستقیم چیه؟چه داستانی؟اتصال به سرور از طریق connection string توی کدها اتفاق میافته و کاربر هیچ اطلاعی از اون نداره.

---

من وقتی میگم درست نیست که بیزینس برنامه بره تو دیتابیس منظورم سیستم های بزرگه ... البته چون شما دارید از برنامه آفلاینتو وصل میشید به بانک آنلاین به صورت مستقیم , میشه کدهای شمارو دیکد کرد و به دیتابیستون وصل شد وقتیم که به دیتابیس وصل شه همچی اون تو هستش (هم داده هم بیزینس) .. شما وقتی بیزینسو بردی رو بانک باید فکر امنیتشم باشی دیگه .. هر برنامه ای که شما بنویسی در نهایت میشه دکدش کرد .. تو بدترین حالت اینه که برنامه به زیان اسمبلی دیکد میشه , ولی میشه , حالا اگه برنامه شما بزرگ نیست نمیخواد زیاد نگران باشید .

نقل قول:

---

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

---

ببینید بزارید راحت بهتون بگم .. شما وقتی میخوایید از یه بانک آنلاین تو برنامه آفلاین ویندوزی استفاده کنید بدترین کار این کاریه ک شما کردی :لبخند: . من این راهو میرم :
1 - برنامه شما تو بانک لوکال خودش بیاد داده هارو نگه داری کنه نه سرور .. (اگه میخوایید برنامه منعطف باشه که دیگه باید یا قابلیت آپدیت داشته باشه ... یا حداقل یه کافیگی داشته باشه که توسط سرور به روز بشه و برنامه رفتارش طبق اون کانفیگ عوض بشه (باید جنرال کار کنید)).
2 - یه وبسرویس مینویسم که برنام از طری اون سرور بیاد پایگاه داده سرور رو با پایگاه داده لوکال خودش به روز رسانی کنه اینطوری هم برنامه آفلاین کار میکنه هم بانک سمت سرور دور از دسترس هکرا میمونه .

نقل قول:

---

یه بانک آنلاین تو برنامه آفلاین ویندوزی

---

منظورتون از بانک آنلاین و برنامه آفلاین چیه؟

نقل قول:

---

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

---

و منظور از بانک لوکال؟کلاینت ها باید داده های بروز شده رو ببینند برا همین داده ها باید رو سرور ذخیره بشه! :گیج:

نقل قول:

---

منظورتون از بانک آنلاین و برنامه آفلاین چیه؟

---

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

نقل قول:

---

و منظور از بانک لوکال؟کلاینت ها باید داده های بروز شده رو ببینند برا همین داده ها باید رو سرور ذخیره بشه!

---

خب پس راهتونو اشتباه رفتین ... شما باید Web Application مینوشتید

نقل قول:

---

خب پس راهتونو اشتباه رفتین ... شما باید Web Application مینوشتید

---

:متعجب: اشتباه؟؟خیلی نرم افزار desktop application هست که client server ی کار میکنن.دیتابیس روی سرور هستش کلاینت ها هم نرم افزار رو در اختیار دارن که نرم افزار هم تمام عملیات رو روی دیتابیس روی سرور انجام میده.من از اول بحثم تا حالا منظورم این نوع نرم افزارا بود.

نقل قول:

---

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

:متعجب: اشتباه؟؟خیلی نرم افزار desktop application هست که client server ی کار میکنن.دیتابیس روی سرور هستش کلاینت ها هم نرم افزار رو در اختیار دارن که نرم افزار هم تمام عملیات رو روی دیتابیس روی سرور انجام میده.من از اول بحثم تا حالا منظورم این نوع نرم افزارا بود.

---

این تیپ نرم افزارها از یه لایه میانی دارن تو قالب Web Service و Web Api و مطمئنا به یه دلیل خاضی اومدن ویندوز فرم یا WPF و .. کار کردن مثلا نیازی به سرویس چیزی بوده ... اگه قرار باشه نرم افزارهای آنلاین تحت دسکتاپ نوشته بشه , انوقت WebApplication ها چه معنی ای میدن ؟؟؟

مثلا شما میتونی تو دامین خود یه Outlook کانفیگ کنی رو سرور خودت ... outlook هم نسخه وب داره هم نسخه دسگتاپ ... همونطوری که میدونیم Outlook یکی از قابلیت هاش Reminder که مثلا منشی برای شما برای فردا ساعت 3 جلسه ست میکنه .. و Outlook باید فردا 15 دقیقه به جلسه یادآوری کنه ... خب اگه WebApplication باشه حتما یابد مرورگر باز باشه .. روی یه تب مرورگر Outlook باز باشه .. اجازه پخش صدا تو مرورگر داشته باشه و غیره و غیره تا این یادآوری انجام بشه ... .
ولی اگه مثلا ویندوز فرم کار کنی میتونی یه سرویس بنویسیکه این تیپ کارارو انجام بده و موقع لزوم برنامه رو برای Alarm داده باز کنه .
تو این مسئله که وب اپلیکیشن جواب مارو نمیده ما باید از نرم افزارهای تحت دسکتاپ استفاده کنیم .. در غیر این صورت اگه وب اپلیکیشن همه نیازهای پروژه رو جواب میده کار اشتباهیه که ازش استفاده نکنیم ... چون خیلی مزیت های دیگه ایم به شما میده وب اپلیکیشن .

حالا بگذریم .. برای شما یه تا راه حل به ذهنم میرسه که بالاتر هم گفتم .. یا برنامه باید به روز رسانی بشه اتوماتیک .. یا منطق بره تو SP و اگر ساختار تغییر نکنه برنامه به مشکل نمیخوره .. یا باید یه چیز جنرال بنویسی که بیاد یه کانفیگی از سرور بخونه .. لاجیک تو سرور داشته باشه و طبق اونها رفتار کنه .