Чому світ .NET не має нічого подібного до рейок / граалей / джанго / роо? [зачинено]


10

Мені здається, що веб-платформи швидкого розвитку збираються докорінно змінити світ веб-додатків.

Минуло п’ять років з часу випуску Rails 1.0 для Ruby, і з цього часу ми бачили Grails for Groovy, Django для Python та Roo для Java.

Але наскільки мені відомо (що, ймовірно, обмежено, будучи прогамером Java / Groovy), для C # немає подібних рамок.

Чи існує така річ? Якщо ні, то чому б і ні?

Редагувати: Цілком можливо, я не вживаю правильних слів, коли кажу "швидкий розвиток", але я говорю про рамки, які, можливо, можуть дозволити вам створити працюючий двигун блогу за 30 хвилин. Ви не могли зробити це розумно, скажімо, Java, Spring та Hibernate, враховуючи різні конфігурації, необхідні для пошуку ваших контролерів, а також конфігурацію та код, необхідні для того, щоб ваші сутності зберігалися та були отримані.

Тому я говорю про рамки, які обробляють усі CRUD з ментальністю конвенції над конфігурацією. Якщо хтось має правильні слова для того, про що я говорю, дайте мені знати.

Відповіді:


5

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

Під основними потребами я маю на увазі реалізацію Постійного постачальника, Контейнеру огляду залежностей, інструменту ведення журналів, платформи MVC, двигуна шаблонів HTML, Початкового набору шаблонів веб-сайтів із встановленими CSS, рамками безпеки та деякою бібліотекою Javascript для AJAX та інші цікаві речі. Рамки, подібні RAILS, упорядковують усі ці рамки та інструменти на основі моделі домену (сутності вашої системи з її атрибутами).

Завдяки принципу "Конверсія над конфігурацією" ці рамки уникають необхідності визначення безлічі файлів конфігурації, як правило, необхідних рам, які вони оркеструють (наприклад, Spring, Spring MVC, Hibernate, Log4J тощо), припускаючи конфігурації за замовчуванням на основі іменування. , структура та метадані, що входять до визначень одного класу.

Завдяки динамічним мовам, якими ці рамки користуються (наприклад, Ruby, Groovy, Python, Clojure тощо), за винятком SpringRoo, який реалізує динамічну поведінку в Java за допомогою AspectJ, функціонал, що належить рамкам під ним, розширюється і надаються розробнику настільки рівномірно та елегантно, що він / вона просто знає про основні технології.

Нарешті, завдяки техніці Scaffold, одиничні тести, інтеграційні тести, контролери та представлення автоматично генеруються для основних функцій (CRUD) над кожним з об'єктів домену, визначених розробником.

У світі .NET ще нічого не було розроблено, дотримуючись усіх попередніх визначень. Але ніщо не заважає це відбутися незабаром. У світі .NET вже існують чудові рамки, інструменти та бібліотеки, які можна організувати за допомогою нової рамки, подібної RAILS, створеної для CLR. Серед потреб Unity, Innection є Unity, Spring.NET та Castle Windsor. Entity Framework 4, NHibernate та iBatis.NET є досить хорошими постачальниками .NET Persistence. ASP.NET MVC наполегливо підтримав різні двигуни шаблонів, окрім традиційних ASP.NET.

Навіть якщо ніхто не домагається використання мови DLR для побудови такого роду рамки, той, хто має достатньо волі, може пройти шлях SpringSource та застосувати RAILS-подібний фреймворк з якоюсь статичною мовою, як F #, C # або VB.NET, використовуючи аспект -Орієнтований контейнер (наприклад, AspectSharp або Gripper-LOOM.NET) для отримання динамічної поведінки.

Мені б хотілося знати про будь-яку групу людей, які намагаються розробити такі рамки в .NET.


4

Я не знаю, що ви маєте на увазі під «веб-платформами швидкого розвитку». Визначення "швидкого розвитку", з яким я знайомий, не має нічого спільного з мовами, парадигмами чи рамками, а скоріше з використанням швидкого прототипування та ітеративної розробки для створення системи. Будь-яка мова або рамки можна використовувати однаково добре.

Я ніколи раніше не використовував Grails або Roo, але Django і Rails - це рамки MVC, тому їх аналог у .NET був би ASP.NET MVC .


1
Ну, я б бачив ASP.NET MVC як аналог Spring MVC. А сказати, що Rails - це структура MVC - це як сказати, що Stackoverflow - це сайт QA, як обмін експертами. Це правдиве твердження, але воно пропускає найважливішу особливість та причину свого дикого успіху.
Ерік Вілсон

1
Поясніть, будь ласка, "найважливішу особливість". Rails - це не що інше, як рамка MVC для мови Ruby. Це все захоплює.
Томас Оуенс

2
Ну, Spring - це MVC-рамка для Java, але вона не робить багато того, що робить Rails і Grails чудовими. Наприклад, за допомогою граалів, після створення об’єкта домену, я можу вводити, grails generate-allа grails створює контролери, перегляди та керуватиме стійкістю.
Ерік Вілсон

3

Ви можете зайти в Visual Studio і перетягнути елементи керування на веб-сторінці і підключити їх до бази даних з мало-без коду. Один клік для тестування / перегляду. І одним клацанням для завантаження на веб-сайт (добре, введіть облікові дані).

Не те, що це найбільш використовуваний або навіть рекомендований спосіб зробити це, але насправді це не набагато простіше, ніж це.


0

Тому що веб-додатки .NET мають цикл збирання.

Ruby / Python є дуже спритними / спритними та динамічними мовами.

Там, де я працюю, у нас є величезний веб-додаток .NET, і терміни компіляції порівнянні з типовою середньою та великою програмою C ++.

У моєму запасі я розробляю веб-додатки в python, а час компіляції - 0. Тут просто немає кроку компіляції. Запуск інтерпретатора просто завантажує файли .py під час їх збереження.


1
Добре, що додатки Java мають цикл збирання, але Spring Roo все ще творить чудеса для додатків Java / Spring. Тож я думаю, що тут є й інші питання.
Ерік Вілсон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.