MVC, WCF, EF, LINQ - це тільки я? [зачинено]


17

... чи все ускладнюється?

Мені здається, що вам потрібно знати багато речей, щоб «правильно» розробити веб-додаток для MS сьогодні. У погані старі часи, коли ми не знали нічого кращого, у нас були таблиці баз даних, ASP.NET, ADO.NET, і ви створили веб-додаток, використовуючи порівняно прості поняття.

Сьогодні, здається, існує багато механізмів, щоб "допомогти" зробити це "правильно", але я не переконаний, що це робить все легше і краще. У мене є відчуття, що я буду в досить невеликій меншині з такими почуттями, але чи є ще хтось там, хто думає, що справи пішли з розуму?


MVC = ASP.Net, WCF = Веб-служби + .Net Remoting, EF = ADO.Net, Linq - це заміна деяких циклів foreach. Зараз є стільки рамок, як і раніше.
вихровий вовк

Джон, я повинен "частково" погодитися з вами. Наразі я вичісую свої навички .Net, звичайно, набагато більше, ніж пройти, ніж 5 років тому.
TeaDrinkingGeek

Незважаючи на те, що на арені MS може бути багато технологій БД, це питання на цьому веб-сайті справді поза темою. Це насправді не задає питання і прямо впадає в "... смокче, я прав?" категорія рейтингу, перелічена у FAQ
Walter

Відповіді:


17

Усі ці речі необов’язкові, використовуйте їх, якщо вони корисні, не - якщо вони не є. Це так просто. Ви, звичайно, можете написати хороші / належні веб-додатки без будь-якої з цих абревіатур у своєму рішенні.

Особисто я вважаю, що MVC є досить легкою та простою у використанні рамкою (набагато простіше розпочати роботу, ніж веб-форми, imo). Так само LINQ пропонує загальний спосіб запиту будь-чого; також добре. У EF та WCF у мене були розбіжності, але коли це так, я не використовую їх.


2
Додайте +1 до "використовуйте їх, якщо вони корисні". Я намагаюся використовувати правило, намагаюся зробити 1 нову 'річ' у кожному проекті. Через деякий час ви отримаєте досвід роботи з великою кількістю матеріалів і побачите, що все стає простішим, оскільки ви більше використовуєте його.
Jan_V

+1 також вам "спробуйте зробити 1 нове на кожному проекті". Мені також подобається вчитися і рости.
Поль,

1
Я намагаюся зробити по 1 новій справі на кожному проекті, але це зазвичай тому, що нова річ, про яку я дізнався останній проект, застаріла :)
gbjbaanb

9

Ні, не дуже. LINQ - це найбільше, оскільки нарізаний хліб під час взаємодії з базою даних.

Що вам слід пам’ятати, це те, що ці речі побудовані на інших речах. LINQ не додає до кількості речей, які потрібно знати, щоб розробити веб-сайт ASP.NET, тому що тепер не потрібно знати SQL. І LINQ - це OO, що набагато більше відповідає регулярній розробці додатків, що робить його повним shitton легшим, ніж SQL, і набагато простіше інтегрувати з C #.

Якщо ви не вважаєте, що LINQ простіше, ніж SQL, можливо, ви повинні розмістити кілька прикладів того, що складніше в нових парадигмах.

Що ще важливіше, раніше веб-сайти мали набагато меншу функціональність. Як ви збираєтеся робити нові веб-сайти, які працюють краще, масштабують краще та пропонують нові функції в одному коді?


4
Ліве з'єднання в LINQ складніше, ніж у SQL. Крім того, якщо ви намагаєтеся вирішити проблеми з базою даних, вам доведеться все одно переглядати SQL. Крім того, знання SQL допоможе вам, якщо ви хочете перейти на платформу розробки, що не належить Microsoft.
btilly

10
Жодна структура ORM не є такою потужною, як SQL. Є запити, які мені доводиться виконувати, поруч із якими неможливо виконати в рамках ORM.
біт-трейдлер

1
@ bit-twiddler> так, і саме тому більшість фреймворків ORM дозволяють також виконувати необроблені SQL (або проростки). У вас може бути хороший хлопець C #, який пише більшість запитів пішоходів, а фахівці з БД, як ви, можете упакувати важкі речі для них у вікно або перегляд.
Павло

1
Хоча я розробляю масштабні бази даних і записую тонну SQL на стороні клієнта та сервера, я не DBA. Я інженер програмного забезпечення. Я ніколи не працював ніде, де розробники програмного забезпечення, де універсал. У будь-який день я можу писати код на мові складання C, C ++, Java, Object Pascal, PL / SQL або Intel (я не вважаю HMTL, XML та CSS як мови програмування, оскільки вони не завершені Turing). Я також підтримую власні набори інструментів і тестове середовище на базі Tomcat (кожен у моїй команді має власний сервер Tomcat).
біт-трейдлер

1
Написання LINQ для взаємодії з базою даних (LINQ-to-SQL, LINQ-to-Entities), не знаючи SQL ...? Рецепт катастрофи.
Кірк Бродхерст

3

Якщо старі концепції, про які ви згадали, більше не працювали, я погодився б, що це було б шалено, але нові рамки - це альтернативи. Сліпе прийняття було б шаленим. Вам потрібно виправдатись. Особисто для мене SQL не є проблемою. Намагаючись додати частину функціональності сучасних веб-сайтів, веб-форми вже не скорочують її.

Я впевнений, що деякі класичні люди з ASP вважали так само .NET, але мало хто може продовжувати робити це. Я будую кілька сайтів у класичному ASP і не повертаюся назад.


2

"Зійшов з розуму". Саме так я б описав рішення DataSetADO.NET, ASP.NET. :)

Я погоджуюся, що можна дізнатися багато іншого, але кожен із згаданих вами кадрів поліпшив розвиток .NET.


0

Я б сказав, що це глобальна проблема, яка може сильно зачіпати будь-яку структуру чи платформу розробника. Коли виходить нова рамка, вона виглядає, як правило, невеликою і компактною, але з часом йде і включаються нові функції / функціональність / API (або дорожня карта / запит, нові концепції / тенденції / технології, або просто еволюція), вона стає "роздутою". Ви почали з "одного способу ведення справ", і тепер є більше можливостей, які ви можете вибрати (і - ви не знаєте / не впевнені - який вибрати). Навчання нових речей може зайняти багато часу, проте вони можуть запропонувати вам набагато більш гнучкі / швидші / кращі рішення тих самих проблем, які раніше вирішувалися обмеженим набором можливостей.

Я одного разу натрапив на кумедну цитату - "весь код перетворюється на s #! T, приділяючи достатньо часу та рук" - який ІМХО підсумовує, чому повинні з'являтися нові речі в існуючих рамках, щоб привести нові ідеї в дію та зробити еволюцію.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.