Умови використання Entity Framework.

1.1. ORM для отримання даних взагалі не потрібен.

Перша й головна неприємна правда Entity Framework, яку будь якою ціною намагаються замовчувати мікрософтовці - що ORM (тобто великий графічний Framework, який робить мапінг табл з SQL-серверу на буфера пам'яті) - взагалі не потрібен для будь якого проєкту. Це важливе порозуміння та воно дорого коштує. Я вважаю, що сьогодні 99% сайтів у інтернеті зроблено взагалі без будь яких ORM. Подивиться, будь ласка, для початку на мою сторінку Variants of ASP NET Technology stack та зрозумійте, про що йде мова. Мова йде про верхню стрічку, правий куточок там - це засоби отримання даних. Тобто існує багато засобів працювати взагалі без ORM, та існують десятка два конкуруючих ORM, найбільш складний з яких саме Entity Framework.

Ось тут, друзі, подивиться, будь ласка, на перелік засобів отримання даних, що я зробив у себе на сайті - Класифікація засобів роботи з даними.

Тобто яким чином можна працювати з даними? Наприклад ось таким, яким я працюю у сайті http://arenda.votpusk.ru/ - на перших двох скрінах декларативний сінтаксіс, на третьому - звичайний, кодом. Тобто щоб писати/читати дані с серверу, не потрібно ні LINQ, ні взагалі нічого, одна стрічка кода SqlDataSource, яку ми або написали в коді (359 на скрині нище) , або просто у вигляді XML безпосередньо у HTML.

На наступному скрині ще один мій новітній проєкт, розробки 2017-го року. Як бачите, він зроблений (на вимогу замовника) без усяких ORM - лише на старовинних DataSet'ах - без будь яких LINQ.

1.2. Застосування будь якого ORM не гарантує успіху проєкту.

Щоб ви краще порозумілися, друзі, ось вам неприємна правда. http://arenda.votpusk.ru/ зроблена мною 10-15 років тому, та наразі має великий комерційний успіх та працює й працює. А мої проєкти, зроблені з найсучаснішими ORM, наприклад Social network for Canada with printed version of calendar to communities, Project with online auction, Сайт с Google-maps API, имперсонализацией и Dynamic LINQ Expression., CMS сайта продажи авиабилетов, //www.vb-net.com/Trudopoisk/Index.htm, Проекты нового Вотпуска., Электронный магазин запчастей SHEL-AUTO.RU на web-сервисах EMEX.RU - хоча останній сайт приносив мільйоні доларів, всі ці проєкти зараз вже давно померли, незважаючи на застосування будь-яких фреймворків. А http://arenda.votpusk.ru/, зроблена на простих SqlDataSource - все працює та працює.

1.3. Якщо ви не плануєте змінювати SQL Engine з MS SQL на інші.

Якщо ви не плануєте змінювати SQL Engine з MS SQL на інші на протязі життєвого циклу проєкту, то існує декілька інших, набагато зручніших ORM, найбільш вдалим з яких я вважаю Linq-To-SQL.

1.4. EF не підтримує MS SQL Server, він дивиться на нього лише як на механізм зберігання табличок.

Зрозумійте, друзі, що MS SQL-server має приблизно 100 вкрай спеціфічних об'єктів, ось тут у мене є їх перелік Программирование в SQL SERVER - починаючи з Aggregate до XML Schema Collection. Ці об'єкти вкрай специфічні для MS SQL, а Entity Framework вкрай універсальне, аж до того, що таблички вім має можливість зберігати у MongoDB (якщо ви не знаєте що це за диво, то будь ласка прочитайте ось тут MongoDB - noSQL-database for irregular JSON data. Зрозуміло, така універсальна річ, яка може працювати на будь якому Engine для зберігання даних на дисках вона принципово не може підтримувати 100 специфічних для MS SQL серверу речей.

1.5. Безглуздий агресивний промоутинг Entity Framework.

Істерика з Entity Framework нагадує мені істерику з Dependency Injection, які я не раз описував на своему сайті Застосування патерну Dependency Injection за допомогою IoC-контейнера Ninject, які взагалі можна уникнути у будь-якому проєкті, якщо його будувати послідовно та розумно.

Або істеричний промоутінг EF нагадую істеріку щодо новітніх JavaScript-фреймоворків. Це взагалі феєричне явище - з мільярдів сайтів, існуючих у інеті всього пара сотен зроблена наприклад на REACT, і є виключний список таких сайтів, я писав про це багато разів Декілька моїх останніх тестових проєктів.. Але якщо ви подивитесь на об'яви щодо роботи, то там будуть тільки об'яви з опитом попередньої роботи на REACT. Але правда в тому, що ви так і не знайдете роботу по цих об'явах, це лише засіб просування й реклами цього JavaScript-фреймоврку.

Така ж точно безглузда істерика у інеті існує з Unit-тестами, які я теж багато разів описував на своєму сайті Unit-тести для ASP.NET MVC. Не існує ніяких доказів, що проєкти, які прошли Unit-тести мають хоча б на 0,01% меньше багів, чем проєкти, які взагалі не мають тестів.

От наприклад я зацікавився мікрософтовским конвертером C# у VB ICSharpCode.CodeConverter. Скачав його, подивився - тести у нього займають немаленьку частку проєкту - як ви можете побачити на першому скріні. Але проєкт цій, незважаючи на усі тести, не працює взагалі. Спробуйте, для приклада взяти будь який C#-текст нище та сконвертувати його у VB. Ви будете неприємно здивовані - будь яка спроба конвертації закінчується аварійно.

Я додав дві стрічки кода, після чого проєкт взагалі перестав конвертувати Атрибути, але після чого він став хоч іноді працювати та щось конвертувати. А як же тести, які йдуть разом з цім проєктом і становлять значну частку кода - спитаєте ви? А ніяк. Це лише реклама, лише моргають кольорові лампочки тестового проєкту. І нічого більше під цім немає. Ну наприклад як сертифікат ISO 9001 у промисловості, він є, але чи він затверджує успіх компанії, доходи власника чи щось інше? Це лише бюрократична справка, під якою немає нічого, крім інших справок, які підготували одни юристи для інших. Так само й тести, під ними немає нічого, крім тих ситуацій, до програміст бажав показати, що існують ситуації, у яких проєкт працює. Але чи буде він працювати у реальних умовах краще, ніж проєкт без тестів та справок - це велике питання.

1.6. Невже все так погано, що EF не потрібен зовсім?

Та невже ж все так погано? Ні, але рішення про використовування EF треба доводити з вагомими аргументами. Потрібно розуміти, що якщо раніше ви з цим великим фрейморком не працювали, то ви можете витратити декілька місяців на навчання, як ним користуватися. А після вивчення ви зрозумієте, що отримали лише крихітні переваги перед простими запросами SqlDataSource та нульові переваги перед Linq-To-SQL (що й мабуть й буде у 99,99% випадків).

Але що то, за 0,01% випадків, коли ви реально маєте переваги перед Linq-To-SQL? Зверніть увагу що це не тільки моя особиста думка, моя особиста думка лише співпадає у цьому випадку з авторами великих підручників по програмуванню, наприклад скріншот на початку цієї сторінки я зробив з підручника - Класифікація засобів роботи з даними.. Взагалі багато людей має щодо EF framework приблизно таку ж думку, що й я, наприклад - Max Ivak blog. Велика кількість програмістів вважає Linq-to-SQL більш гнучким та могутнім фреймоворком, у інеті безліч приблизно ось таких постів - LINQ to SQL is far more 'agile' and flexible than Entity Framework. Найбільш важливою я вважаю оцінку самого Мікрософту, Introducing LINQ to Relational Data. Зазвичай мікрософтовські лінки раптово зникають, тому ось вам локальна копія цієї ж статті з MSDN. Та давайте ще раз подивимося на таблички з цієї мікрософтовскої статті:

Нажаль Мікрософт з часом стала грати в якісь свою нікому незрозумілу гру та припинила розвиток Linq-to-SQL. Ну взагалі це дуже звична ситуація, пройде два-три роки і мікрософт (як і завжди це робила раніше), зробить заяву, що EF була помилкою.

Зверніть увагу на найбільш важливу та цікаву особливість - Мікрософт припинила розвиток БЕЗКОШТОВНОЇ версії LINQ-to-SQL (бо вона вийшла занадто гарною для безкоштовного фреймворка), і тепер LINQ-to-SQL далі активно розбудовується як ПЛАТНИЙ фреймоворк, це робить devart та ще сто компаній меньшого розміру. Звичайний мікрософтовський L2S компанія DevArt значно поширила, по-перше у версії DevArt він підтримує будь який поширений SQL-server, тобто MS SQL Server, MS SQL Server Compact, Oracle, MySQL, PostgreSQL, SQLite. А також має ще багато різноманітних поширень, яких не має Linq-to-SQL від Microsoft, а саме має вбудований PLINQ, Inheritance тобто наслідування об'єктів, предкомпільовані Query, unions/intersect Query, object materialization та ще мільйон особливостей, яких не має й близько найсучасніший мікрософтовський фрейморк. Найбільш мені подобаються у подальшому розвитку Linq-to-SQL від DevArt оновлення даних чистими POCO-класами з атрибутами.

Але, якщо повернутись до безкоштовних ORM від мікрософту, то я вважаю, що існують деякі виняткові ситуації, у яких застосування Entity Framework виправдано:

• Ви використовуєте MS SQL (чи інший сервер) екстремально поверхово, і взагалі прі нагоді плануєте відмовитись від існуючого SQL-сервера та перейти на інший, наприклад ви плануєте у майбутньому переїхати з Windows-хостингу з MS SQL на UNIX-хостинг з PostgreSQL. Але $250 на платний Linq-to-SQL, який підтримує будь які SQL-сервери, ви не маєте.
• Ваш проєкт розрізано на багато незалежних окремих частин, власник проєкта бажає зберегти свою власність таким чином, щоб програміст сайта не мав доступу до бази, працював лише с POCO-класами, тобто буферами у пам'яті. Хтось зовсім інший (можливо навіть у іншій країні) робив базу, а хтось невідомий робив кліентську частину, що працює у браузері. Адмінку також роблять зовсім інші люди - й так далі. Так, насправді, у цьому випадку, EF - найзручніший засіб розрізати проєкт і відокремити програмістів одне від одного, зробити так, щоб ніхто не побачив повного проєкту.
• Ви необмежені у грошах і маєте можливість використовувати SHARED-хостинг від Мікрософт - AZURE, найбільш дорогий у світі і найбільш незручний для використання. Але він дуже добре підтримує Entity Framework. Мова йде саме про SHARED-хостинг на AZURE (тобто це колишній WebMatix), а не про окрему віртуальну машину VmWare - у випадку окремою віртуалки, навіть закуплену у найдорожчому дата-центрі у світі, у Мікрософтовському - переваг у EF над Linq-to-SQL немає.
• Умови виготовлення вашого проєкту такі, що потрібно демонструвати замовнику тести. Ну про те, що на якість програмного продукту це не впливає, я вже показав вище достатньо конкретно на скрінах, але ви маєте УМОВИ, які неможливо обійти. Тоді, насправді, важко уникнути використання EF (у межах безкоштовних фреймворків).
• Ви теоретик програмування, або починаючий програміст - ви дуже добре розумієте різноманітні патерни програмування, такі як описані тут Теоретичні питання програмування., але з якихось причин ви зовсім не розумієте мову й принципи роботи SQL-серверу, з тих же самих загадкових причин фантастично добре розумієте найскладніші варіанти використання специфічної мови LINQ. Можливо ви тільки починаєте свою кар'єру програміста, можливо ви прочитали про програмування лише одну книжку, або можливо це єдине чому ви навчилися у інстітуті - ні про що, крім LINQ, патернів, та EF ви взагалі не чули. Та щоб використати у реальному проєкті щось інше, крім EF, вам потрібно спочатку витратити великі зусилля й час.
• Вам набридло працювати швидко та за звичним порядком багато років. Якщо можна працювати нешвидко, та хтось за це платить гроші, та ще й можна розважатися на роботі (на кшталт розгадування кросвордів), то чому б не повчитися чому не будь новому та незвичному? Я десь рахував, скільки мільйонів бібліотек існує у інеті, наприклад лише https://sourceforge.net/ та https://github.com/ зберігають мільйон різноманітних фреймфорків-бібліотек. Чому б не повчитися ще одному великому API (ось тут є пару його корисних описів tutorialspoint, codeproject) де лише короткий перелік можливостей складає книжку на 290 сторінок, це без LINQ, без Expression, які потрібні для користування EF. Та взагалі для вилучення користі з EF взагалі майже всі можливості Visual Basic 2015 потрібні - чому б не порозважатися, якщо хтось за це платить?
• Якщо ви рахуєте, що існує ще якийсь випадок, у якому використання EF має сенс, напишіть мені це, будь ласка, нище у коментах до сторінки.

< THANKS ME>