Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Принцип выбора технологии C# vs Java заказчиком?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Возможно такой вопрос уже был на ДОУ, но я его не нашел ...

Сейчас эпидемия Джавы достигла апогея, кучище вакансий от трейни до архитектора, школьники с книгой Хорстманна в руках мечтают что уже через месяц все IT-компании будут их лопатой загребать и платить over9000 зелёных денег только за то, что они умеют открыть Эклипс.
Конечно это всё хорошо, да и на Джава написано больше проектов чем на C#, но блин этот C# афегительно удобен и не только Вижуал Студией, ASP.NET — просто превосходен, работа с БД это вообще два клика, всё удобно, сам язык очень «сахарный», документация выше всяких похвал и без неё на любой вопрос уже есть ответ, как по мне так на «Шарпе» разработка будет происходить быстрее. Когда-то копался с Джава и его хороводом серверов и фреймворков и как-то не пошло у меня с ней и тут на помощь мне, пришел C# - просто инструмент моей мечты ! Неужели на Java можно сделать то, что нельзя сделать на C# как по мне так наоборот и то что дело в цене я тоже сомневаюсь, у Джава там куча лицензий и всякой хрени ну конечно «Шарп» немного по дороже будет но тогда нафига работать с «Шарпом» давайте всё на Джава напишем ... Или дело всё таки в цене ?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

По таким темам можно сразу определить профанов, которые будут доказывать у какого языка круче фичи, тот и надо выбирать.Однако заказчик не программист, и ему все равно насколько язык продвинутый, иначе все бы писали продакшен на хаскелее, зато при выборе аутсорсера-партнера его волнуют.

1) Цена вопроса. // Зарплаты, оборудование, командировки, стоимость лицензий
2) Риски // Кастомер не хочет рисковать и делать продукт на нестабильном тех. стеке.
3) Наличие своего технического специалиста, архитектора(ов).
4) Vendor lock-in. Т.е. зависимость от внедора стека, если она есть это хуже чем если бы ее не было, так как это дополнительные затраты и риски.

Короче, в конечном счете все сводиться к двум вещам, рискам и затратам. .NET и MS Стек проигрывает Java, за счет:
1) Многоплатформенность дешевле, не нужно покупать Windows Server, если можно взять linux.
2) Java стек более зрелый и что самое главное стандартизированный, новые версии JavaEE технологий имеют обратную совместимость, как и сама джава, что облегчает сопровождение, уменьшая риски и затраты.
3) Vendor lock-in опасная штука, а если еще взять во внимание конкурентную политику M$, то жить вообще становиться страшно.

У .NET впрочем есть преимущество в хорошем сопровождении для кастомеров, однако такая же услгуа есть у Jboss.

Поэтому, в силу меньших затрат и рисков, заказчик чаще выбирает Java для своего бизнес-проекта. Хотя, там где есть легаси системы, которым нужно быть совместимыми с новым, там где в случае провала можно подать в суд, там конечно преимущество MS бесспорно.

ИМХО, какой стек у компании ведущий — тот и выбирают. А основной стек может быть выбран как угодно, ну например: чьи продажники раньше дорвались до конторы или программистов на чём нашли.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Работать с продуктами Мелкомягких себе дороже. Я вообще не понимаю их политики, вечно в поисках грааля. Был афигенный Silverlight, всё нафиг с пляжа, поддержка до 20 года и «забили». XNA — только разобрался «что почём» и как работает, тоже в топку, не пошло, а как они усырались на ДевКоне какая это супер штука, теперь с 2014 даже баги фиксить перестанут. Windows Phone 7 — прорыв в мобильном мире, супер ОС для мобилы разрывая ж0пу говорил Балмер, но теперь у нас есть новая вещь WinPhone 8 и если ты отдал 600 баксов за Nokia Lumia 900 то выкинь её нафиг потому что обновится у тебя не получится — «ЧУДЕСНО» ! И тут люди говорят о новой Windows Phone 9 котрая будет написана с нуля и совершенно новой ОС — АХРЕНЕТЬ ! А может им нужно вообще «забить» на Windows /.NET Framework/C#/ ASP.NET и обьявить : Мы склепали новую ОС «Двери» с новым каркасом «.YES Framework» под которую рекомендуем разрабатывать на новом языке «C##» и ASP.YES — так это не шутка, эти Мелкомягкие могут сделать что угодно, уже каждый год новую «студию» клепают за 2к баксов ! Называется жри что дают ...

за 2к баксов
11к ультимейт стоит

Афигеть можно от цен Мелкомягких ! Да у меня машина дешевле, совсем ахренели просить такое нереальное бабло за эту IDE. Хотя многие чисто для себя используют такую студию от Торрент Эдишн и не парятся давать денежку Мелкомягким.

за 2к баксов
Professional 800 стоит, а еще есть MSDN подписки...

800 тысяч баксов ? Мелкомягкие совсем аxуели ...

Коментар порушує правила спільноти і видалений модераторами.

Ну вообще немного не спокойно что Майкрософт может резко повернуть в другую сторону и ты останишся не у дел, но вероятность мала ! С другой стороны если .YES Framework будет круче и интересней то почему бы и нет ?!

.YES Framework может быть только на другой ОС например «Doors XP» или «Doors 9» а это уже большая проблема но возможность такая есть, людей же как-то пересадили на Vista\ 7 хотя под XP была уйма приложений, пришлось много чего переписать, а под Doors 9 они сделают суперскую совместимость, например под приложения Windows афегительно быстро запустится виртуальная машина и запустит вам Нейро 10. Но разработчикам всё же прийдется переучиваться под .YES Framework и C## !

Почитайте что такое com и почему появился .Net и перестаньте писать глупости.

почему появился .Net
Потому что Сан продинамило МС с внесением в джаву виндовс-специфичных фишечек?
Почитайте что такое com и почему появился .Net и перестаньте писать глупости.
Чувак таки загнул с сарказмом. Но суть остается такой же:
В мире МС-разработки есть 1 вендор и он определяет куда движутся все разработчики. И если он решил что ВижулБейсик не нужен иди и учи ВижуалЦПП. Выучил? Молодец, теперь все выброси и учи Ц№. И обязан использовать Силверлайт, хотя стоп, уже не надо, ибо все новые тулы и разработки будут ориентированы на ХТМЛ5. И подобных примеров множество, за последние 20 лет МС несколько раз меняла «мейнстрим».
А когда у вас нет вендора-диктатора, то развитие происходит эволюционно, а не революционно. То есть если вам нравится Стратс, которому уже 13+ лет, пользуйтесь и в него будут добавляться новые фичи (ну или сами добавляйте).

мс разрабы обычно не жалуются на то, что им раз в два года нужно привыкнуть к какому-нибудь razor’y. Вероятней всего потому, что за несколько лет вместо 50 строк кода они начали писать 10 для решения одних и тех же задач.
С точки зрения платформы и процесса разработки грубо все это либо удобный .net которому уже десяток лет, либо неудобный com, который в два раза старше. В любом случае жизненный цикл более чем достаточный для того, что бы приложение жило и развивалось и его не надо было переписывать каждые 2-3 года. Хотя в бизнес реалиях это вполне нормально.

мс разрабы обычно не жалуются на то, что им раз в два года нужно привыкнуть к какому-нибудь razor’y.
А их манагеры (заказчики), которым надо вливать доп деньги в __переучивание__ сотрудников? А то что кроме привыкнуть, надо еще и притереть новую технологию к старой?
В случае с эволюционным развитием, эта проблема стоит меньше, так как технология как правило приходит от исполнителей и они уже овладели ей в какой-то мере. В случае с «диктатурой»: вы или переучиваетесь (даже если для этого нет необходимости), или потихоньку помираете.
В любом случае жизненный цикл более чем достаточный...
Угу вот клепали вы 5+ лет на ВебФормс и тут оказывается что надо писать под МВЦ (я шас про фреймворк). Ух как это занятно рассказывать людям на собеседовании что им таки прийдется хотя бы баги фиксить на устаревших технологиях и даже если они их не знают, то надо будет осваивать, банально для багофикса. Или же альтернатива: переписать ффсе; но тут мы возвращаемся к вопросу денег, времени и прочих ресурсов.
Хотя в бизнес реалиях это вполне нормально.
Сильно зависит от ... . Знаю случаи ухода с платформы МС по причине такого вот бардака, но правда там это форсили как раз технари, а не бизнес-люди.
А их манагеры (заказчики), которым надо вливать доп деньги в __переучивание__ сотрудников? А то что кроме привыкнуть, надо еще и притереть новую технологию к старой?

Новая технология всегда или практически всегда совместима со старой, .net совместим с com, mvc c WebForms в рамках единого проекта.
Революции если и происходят, то с объективными предпосылками, а не по коммерческой необходимости мс. Хотя то, что они отказываються от каких-то локальных казалось бы новых технологий можно списывать на их коммерческую политику. Но применение этих технологий не ограничивает производителя ПО под мс настолько, что ему из-за этого надо было кровь износу за 3 или 5 лет полностью сменить архитектуру приложения.

Новая технология всегда или практически всегда совместима со старой
Повторяю: речь не столько о совместимости, сколько о навыках разработчиков.
Например:
У вас был ком на кошерном ЦПП (бо ВижаулБайсик, как мейнсрим, отменили ранее), а стал дотНет или на Ц№ или на кастрированном ЦПП.
У вас был Вин32 АПИ, стал МФЦ; был МФЦ, стал ВинФормс; был ВинФормс, стал МПФ; а потом и его отменили ибо «ГУИ не нужен» все в веб и/или ХТМЛ5. (При том все эти технологии все еще существуют и даже совместимы между собой ... в какой-то мере).
Результат: ваши разработчики очень заняты переучиванием технологий, место развития продукта и изучения/создания новых подходов.
Революции если и происходят, то с объективными предпосылками, а не по коммерческой необходимости мс
Если у вас все ситуации одинаковые, то тогда да. Но в реальном мире, все ситуации разные и то что для одного повод для «революции», для другого нормальная рабочая ситуация.
У вас был Вин32 АПИ, стал МФЦ; был МФЦ, стал ВинФормс; был ВинФормс, стал МПФ; а потом и его отменили ибо «ГУИ не нужен» все в веб и/или ХТМЛ5.

Никто не принуждает такой изврат в реальной действительности. Бизнесс-логика на месте в библиотеках и может жить отдельной жизнью хоть еще со времен com либ написанных на ++ и предоставлять интерфейсы для взаимодействия из любого WPF проекта, как например interop.office, все остальное в части гуи решается по мере появления реальной необходимости, а не слепого движения за трендом.
В том числе и переквалификация сотрудников. Ведь возможно такое только в единичных продуктовых компаниях которые существуют уже больше 20 лет, вроде мс. :) Они деньги найдут я думаю, тем более получая каждые 5 лет соотвествующий прирост продуктивности и труда и прирост производительности.
По факту это развитие, и на данный момент развитие таким темпами, которым java может только завидовать.

Никто не принуждает такой изврат в реальной действительности.
Еще раз: принуждает сама реальная действительность, так как надо фиксить баги и надо нанимать людей (которые, в большинстве, не рады возможности поработать с устаревшей технологией)
В том числе и переквалификация сотрудников. Ведь возможно такое только в единичных продуктовых компаниях которые существуют уже больше 20 лет
Или в мега-гиганстких корпорациях, где обновить браузер (или версию дотНет фреймворка) — это целый проект на года.
Или для небольшой продуктовой конторе, которой стало сложнее набирать людей на «старую унылую технологию».
Или для гигантского аутсорсера/консалтера, которому надо вкладываться в обучение персонала.
По факту это развитие, и на данный момент развитие таким темпами, которым java может только завидовать.
1) И снова лол. Большая часть функциональности (именно функциональности, а не шашечек) дотНета в среде джавы есть уже 5-10+ лет. Есть примеры — озвучьте.
2) И почему это должно быть положительным моментом для заказчика? Для бизнеса.

Первые упоминания о джаве лет на 5 имели место раньше .нета. Попробую принять это как аксиому, что какие-то фичи в среде джавы уже были за 5+ лет до ее появления. :)
Или принять как аксиому надо то, что большая часть функционала была слизана у джавы, кроме шашечек?

По вашему мнению заказчика-бизнесс больше волнует знание передовых технологий разработчиком платформы, нежели его продуктивность труда?

Или принять как аксиому надо то, что большая часть функционала была слизана у джавы
Я такого не говорил. Я сказал что развитие идет не такими уж и быстрыми темпами и при этом во многом догоняя джава. И даже говорить что темпы быстрее чем у джавы (экосистемы), так же не совсем корректно. Но это не столь важно.
По вашему мнению заказчика-бизнесс больше волнует знание передовых технологий разработчиком платформы, нежели его продуктивность труда?
Кто такое сказал?
Продуктивность важна. Но вот
1) продуктивность не зависит от того что МС так сказал. Продуктивность на старых технологиях может быть выше, за счет экспертизы работников. Используя стек МС вы лишаете себя выбора и обязаны двигаться так как решил МС, и тут не важны их мотивы («зарабатывание бабла» или «нести свет и добро»).
2) вливать бабло каждые 5 лет для того чтобы она не просела (переучивать людей) — это как-то не прикольно.
На передовые технологии в большинстве своем бизнесу так же наплевать. Но в случае с МС реальность их подталкивает к обновлениям, даже если они не нужны.
Прочитайте еще раз:
dou.ua/...ic/7922/#349914
а как они усырались на ДевКоне какая это супер штука

Видел ДевКон про «сервелат» ... мда, обнадеживали и очень сильно !!!

Где сексуальнее XML конфиги там и джава =)

уровень комментариев просто обескураживает

похоже, 23х летние синьоры и впрямь уверовали в свою исключительность, и исключительно по тому праву, что они у них в контракте написано «синьор» и им 23

ЗЫ аффтар, ваша выборка нерелевантна (а точнее, никакой выборки у вас нет) — я, практически, гарантирую это
вы, ежели об эпидемии речь ведете — с цыхрами выйдите: вот жаба, вот диез — такая ситуация

а то все это болтовня пустая

как-то про JVM языки ещё не вспомнили, а зря.
Джава оччень хорошо дружит с разными Груви и пр.
так что если по-чесноку и без яги, то очевидно: всякие там школоские сосули неуместны.

http://соснули.рф/

http://соснули.рф/
В Москве бабло, а в Питере поребрик, шаверма и парадная ©

Как раз читал статью почти по этому поводу blogerator.ru/...monk-statistika

Корреляция популярности языка и платформы кажется довольно очевидной. Но никаких убедительных данных об устойчивой динамике роста популярности java по отношению к c# здесь не приведено. java изначально существенно превосходила по рейтингу c#, с годами разрыв сократился, хотя благодаря платформе Android этот процесс почти затух.


Наиболее сильные точки роста наблюдаются там, где удачные сами по себе языки органично накладываются на популярность их родной платформы. Прежде всего я имею в виду стремительный взлет Objective-C, а также «неувядающий в веках» Java, популярность которого в последнее время весьма заметно допингуется со стороны Android. Впрочем, тот же фактор может развернуться и в отрицательный знак, как, например, спрос на Objective-С, который медленно падает вместе с сокращающейся в последнее время рыночной долей iOS, — здесь судьба языка становится заложником родной платформы.

В рамках этого тренда стоит упомянуть, что выход Windows 8 заметно подстегнул популярность C#, который показывает наиболее сильный прирост в последнее время (кстати, по версии PYPL — это был самый быстрорастущий язык в 2012 году).

цитата наглядно показывает ослиные уши IT блаблоггератора
феерично:

«неувядающий в веках» Java, популярность которого в последнее время весьма заметно допингуется со стороны Android.
как вам термин «допингуется » ))
наверно, автор считает что Андроид стал допингом для умирающей старухи -Джавы.
а дополнения в 7-8 й версиях SE то так, мелочи, некогда мыслителю вникать.

Мне термин не кажется удачным. Допинг — запрещенный прием, а корреляцию популярности платформы и языка смешно рассматривать с точки зрения морали, тем более что влияние обоюдно. С другой стороны, долгожданное появление лямбда функций, основной новации в java-8, с точки зрения языка c# трудно считать таким уж революционным. И честно говоря, мне как-то проще думать про интерфейс, содержащий в точности одну функцию (@FunctionalInterface), просто как про функцию. И на практике мне не особенно требуются интерфейсы с константами и прочими завитушкми, enums с методами, wildcards и прочая такая лабуда. Посему c# как язык мне кажется продуман и организован получше. Но конкуренция языков в сущности служит их взаимному обогащению, так что пусть расцветают сто цветов.

оракул стремится угодить любителям сладкого, ценителям лябд и особенно г*внокодерам.

Вот что сделает уважающий себя *овнюк, если он изменил метод и он теперь бросает новый эксепшн, ещё один.
Раньше бы этот засранец написал try{}catch{//do nothing}
А теперь в 7-й Джаве он элегантно добавит новый эксепшн в chain. И не задокументирует. А если спросят wtf то он важно ответит что код- лучшая документация ))

Разработчики расширений языка просто пытаются заасфальтировать уже протоптанные тропинки. Вряд ли они так уж виноваты в том, что достаточно безобидный предмет в кривых руках может стать миной замедленного действия.

сам язык очень «сахарный»
про Scala слышали?

Я смотрю кто-то решил не заморачиваться и пошел проторенной и проверенной дорожкой для организации срача.

Хацкер наелся, спит.
Всё затихло.

Хацкер наелся, спит.
Всё затихло.
99 коментов после моего последнего визита

то по инерции.
не знаю как в америке, а тут вечерком среди тишины-благодати один собакен начинает ґавкать — другие подхватывают.
и так до глубокой ночи.
зачинщик спит уже, а остальные ґавкают.

дайте и я наброшу
виндоус адский выкидыш выношенная индусами для школьников
что бы задрачиваться в варкрафт
что?он ещё и платный и гиг оперативы жрёт?нафиг, ie туда же, unix наше всё
визуал студия
что?кликалка за деньги затмившая eclipse да ещё на виндоус ?нафиг,notepad++ для трушных прогеров
C#
что?засахеранная жаба?зачем?зачем я паттерны учил?нафиг,гоф наше всё
заказчик
что? на пиашпи хотите как в контакте?отличный выбор

проторенной и проверенной
Масло маслянное.

арр. 200 комментов
отписался

Наконец-то подходящий пост для этой картинки: img.artlebedev.ru/...185983085-1.jpg

чистый такой)
индивидуальный, на одного юзера.

Работа с БД в два клика — абсолютное зло. Но это становится ясно только когда объем базы вырастает выше некоторой критической величины.

Но это становится ясно только когда объем базы вырастает выше некоторой критической величины.
и уже немного поздно.

В Джаве один только JPA чего стОит.
Переключился в XML на другую БД и дальше поехал на том же коде.

Я так понимаю, в вашей команде нет аналитики, BI и бд просто хранит последние посты в блоге?

Зависит от обстоятельств. До этого объема базе нужно еще дорасти (и вовсе не факт, что этот момент обязательно наступит для каждого приложения). А читабельность кода, простота внесения изменений — тоже многого стОят, в особенности на начальных этапах разработки.

Я не в теме насчет C#, но Django ORM в свое время произвела на меня очень сильное и приятное впечатление. Это как перейти с ассемблера на язык высокого уровня.

А читабельность кода, простота внесения изменений — тоже многого стОят, в особенности на начальных этапах разработки.

Я понимаю, что это сугубо индивидуально, но лично для меня более читабелен SQL, чем заклинания ORM, которые транслируются в черт знает что.

М-да... Похоже, что это просто ужас как индивидуально. Или же вы не очень в теме насчет того, в чем прелесть ORM. Его «заклинания» наверное действительно ничем не лучше SQL-кода, когда надо написать один запрос. Но с помощью ORM легко и просто можно переходить от объекта к объекту «по цепочке», а вот это уже действительно удобно и фантастически эффективно в плане скорости разработки.

Примечание: ORM, конечно же, ни разу не является серебряной пулей и его использование уместно только для решения достаточно узкого круга задач, в который, тем не менее, легко влезают 90+% веб-проектов, и комфортно себя чувствуют до определенного уровня нагрузки.

объем базы вырастает выше некоторой критической величины.
легко влезают 90+% веб-проектов, и комфортно себя чувствуют до определенного уровня нагрузки.
Думаю Nick Mukhin говорил про оставшиеся 10%
Но с помощью ORM легко и просто можно переходить от объекта к объекту «по цепочке», а вот это уже действительно удобно и фантастически эффективно в плане скорости разработки.
До тех пор пока система не вырастет до определенного размера (в том числе и в ширину) и ваши ОРМ-запросы не начнут превращаться в тонны СКЛ.
Но к этому моменту дизайн системы уже будет такой что написать СКЛ руками будет очень сложно (или результат будет не сильно лучше ОРМа) — это и есть основная проблема «работы с БД в два клика».
До тех пор пока система не вырастет до определенного размера (в том числе и в ширину) и ваши ОРМ-запросы не начнут превращаться в тонны СКЛ.
Но к этому моменту дизайн системы уже будет такой что написать СКЛ руками будет очень сложно (или результат будет не сильно лучше ОРМа) — это и есть основная проблема «работы с БД в два клика».
Ты всерьез думаешь что в мире не существует не криворуких программистов?

Интересно, каким образом использование ORM может негативно влиять на дизайн системы. И/или усложнять ручное написание SQL. :) Богдан, позвольте поинтересоваться, есть ли у вас опыт использования ORM на практике?

просто ручной sql потом как-то надо «вкрутить» (смаппить) в обьекты орм

Интересно, каким образом использование ORM может негативно влиять на дизайн системы. И/или усложнять ручное написание SQL. :)
Есть ентити в нем поле другая ентити в той еще одно, где-то песередине этого всего ссылка на еще одну. В результате при работе на уровне объектов все более мение нормально выглядит, хотя возможно и медлено (лейзи-мшейзи), а запрос получаетсо с кучей таблиц.
Богдан, позвольте поинтересоваться, есть ли у вас опыт использования ORM на практике?
Та куда уж мне, ОРМами пользовались в этом чатике только вы.
Но к этому моменту дизайн системы уже будет такой что написать СКЛ руками будет очень сложно (или результат будет не сильно лучше ОРМа) — это и есть основная проблема «работы с БД в два клика».
— мне непонятно, каким образом ORM портит дизайн системы и как он усложняет написание SQL. Если в системе вылезло несколько «узких мест» — можно поисправлять проблемы «точечно», воспользовавшись raw SQL в нужных местах. Если всё совсем плохо — что ж, значит у нас яркий пример тех 10%, где использование ORM неуместно.
— мне непонятно, каким образом ORM портит дизайн системы и как он усложняет написание SQL.
Ну какбэ вот:
Есть ентити в нем поле другая ентити в той еще одно, где-то песередине этого всего ссылка на еще одну. В результате при работе на уровне объектов все более мение нормально выглядит, хотя возможно и медлено (лейзи-мшейзи),
__а запрос получаетсо с кучей таблиц__.
И если вы с таким не сталкивались, то уже у меня возникают вопросы вроде:
позвольте поинтересоваться, есть ли у вас опыт использования ORM на практике?
И насколько «глубоко» вы их использовали?
Если всё совсем плохо — что ж, значит у нас яркий пример тех 10%, где использование ORM неуместно.
Тут как в анекдоте:
— Ты зачем оторвал коту яйца?
— Я больше не буду.
— А ему больше и не надо!

Ну смотрите. У меня есть опыт допиливания больших, тяжелых и замороченных оракловых проектов. Там простыни SQL-кода на несколько десятков экранов, хранимые процедуры на PL/SQL и т.п. Никому, наверное, и в страшном сне не придет в голову как-то прикручивать к этому ORM. Яркий случай из наших 10%.

Также у меня есть опыт работы с Django ORM, и я вижу, что для специфических для веба задач она просто чудо, как хороша. В критических местах можно обратиться к raw SQL. Даже если вдруг всё приложение придется переписать на raw SQL — мы все-равно сэкономили кучу времени, потому что у нас уже есть готовая БД, оттестированная логика работы приложения, готовые наброски SQL-запросов (смотрим, что и как мы доставали через ORM), и самое главное — пока нам хватало производительности ORM — цена внесения изменений код всё это время была на порядок меньше, чем в случае разработки всего сразу на raw SQL.

В общем, я думаю, что случайно спутать два вышеприведенных варианта (и ошибиться на старте с выбором подхода) почти невозможно. И я думаю, что даже в том случае, когда по каким-то причинам наше приложение начинает требовать перевода на чистый SQL — это печально, на это потребуется время, но скорее всего не больше времени, чем на разработку на SQL с нуля. Как-то так. )

Upd.: Но это не значит, что есть смысл использовать ORM, если есть большая вероятность, что у нас все-таки в итоге получится проект 1-го типа.

больших, тяжелых и замороченных оракловых проектов.
Это не про ОРМ.
Django ORM, и я вижу, что для специфических для веба задач она просто чудо, как хороша. В критических местах можно обратиться к raw SQL.
А это про ОРМ.
В критических местах можно обратиться к raw SQL.
Итого ваш опыт с ОРМ — это простенькие задачки, а как только простенькие задачки, а как только что серьездное вы использовали СКЛ, то есть ОРМ в полной мере не использовался.
мы все-равно сэкономили кучу времени, потому что у нас уже есть готовая БД
Ну генераторы БД и миграции — это немного другое.
готовые наброски SQL-запросов (смотрим, что и как мы доставали через ORM)
И там реально что-то адекватно заменяющее ваш опыт из ораклового проекта (там где тонны СКЛя)?
Можете мне не верить, но факт простой, работая чисто с ОРМ (чего вы не делали, как я понял) вы натолкнетесь в какой-то момент на то что писать СКЛ для задачи будет крайне сложно, а то что генерит ОРМ или тормозит, или не работает.

Вы так покромсали контекст (конец цитаты на слова «готовая БД», например, как будто так и было %) ), что я, честно говоря, потерял надежду донести до вас свою точку зрения. Хотя возможно это камен и не в ваш огород, а в мой.

очень неоднозначный тезис. Поделитесь конкретными примерами? Разве определяющим есть не сама БД? Если на стороне клиента вдруг стало невозможно нормально работать с большой базой то здесь по-моему надо не в клиент писать простыни из сиквел запросов с десятками хинтов и ругаться на прямолинейность ОРМ решений.

По таким темам можно сразу определить профанов, которые будут доказывать у какого языка круче фичи, тот и надо выбирать.Однако заказчик не программист, и ему все равно насколько язык продвинутый, иначе все бы писали продакшен на хаскелее, зато при выборе аутсорсера-партнера его волнуют.

1) Цена вопроса. // Зарплаты, оборудование, командировки, стоимость лицензий
2) Риски // Кастомер не хочет рисковать и делать продукт на нестабильном тех. стеке.
3) Наличие своего технического специалиста, архитектора(ов).
4) Vendor lock-in. Т.е. зависимость от внедора стека, если она есть это хуже чем если бы ее не было, так как это дополнительные затраты и риски.

Короче, в конечном счете все сводиться к двум вещам, рискам и затратам. .NET и MS Стек проигрывает Java, за счет:
1) Многоплатформенность дешевле, не нужно покупать Windows Server, если можно взять linux.
2) Java стек более зрелый и что самое главное стандартизированный, новые версии JavaEE технологий имеют обратную совместимость, как и сама джава, что облегчает сопровождение, уменьшая риски и затраты.
3) Vendor lock-in опасная штука, а если еще взять во внимание конкурентную политику M$, то жить вообще становиться страшно.

У .NET впрочем есть преимущество в хорошем сопровождении для кастомеров, однако такая же услгуа есть у Jboss.

Поэтому, в силу меньших затрат и рисков, заказчик чаще выбирает Java для своего бизнес-проекта. Хотя, там где есть легаси системы, которым нужно быть совместимыми с новым, там где в случае провала можно подать в суд, там конечно преимущество MS бесспорно.

все бы писали продакшен на хаскеле
Как там Yesod и Happstack поживают?

Давно уже не слежу за хаскеллем, наверное повзрослел.

А за развитием этой истории следишь?

>>> www.computerworld.com/...ge_says_Gosling

“Oracle’s recent move to sue Google over alleged Java patent violations in the Android mobile OS has churned up debate over Oracle’s intentions for the language.”

Интересно, чем это закончилось.

если оракул не_дурак (а это очевидно), то закончится ничем.

: /

>>> blogs.apache.org/...esigns_from_the

“...we believe that while continuing to fail to uphold their responsibilities under the JSPA, Oracle provided the EC with a Java SE 7 specification request and license that are self-contradictory, severely restrict distribution of independent implementations of the spec, and most importantly, prohibit the distribution of independent open source implementations of the spec. Oracle has refused to answer any reasonable and responsible questions from the EC regarding these problems.”

А за развитием этой истории следишь?
>>> www.computerworld.com/...ge_says_Gosling
«Oracle’s recent move to sue Google over alleged Java patent violations in the Android mobile OS has churned up debate over Oracle’s intentions for the language.»
Интересно, чем это закончилось.
Лол, с разморозкой, оракл уже год как проиграл и заплатил сколько то там лямов судебных издержек.

Вы описали важные причины выбора платформы и совершенно предвзятое мнение по этим пунктам о превосходстве Java. .
1) Даже первый пункт со стоимостью Windows сервера. Для серьёзной крупной компании это вообще не повод выбора. Там как правило зоопарк технологий и куча ранее купленных лицензий. Для мелкой есть различные программы типа бизспарк
2) Критерий зрелости для этих технологий уже не столь уместен. На языках много чего написано, им более 10 лет. Стандартизирован ли хорошо джава я не знаю, но C# - да. Документации лучше не встречал. Основную вину джаве вменяют за редкое обновление версий и застой. Кто-то говорит что и не надо мол, но тут бабка на двое сказала. В общем спорный-спорный вывод.
3) это единственное что мне приходит в голову как реальная причина выбора. Ещё можно добавить наличие программистов здесь и сейчас. Что Васе-архитектору больше нравилось (при равных внешних факторах), то он и будет проталкивать, убеждая в том, что джава или .net лучше. А нравится это всегда = (твой положительный опыт — твой отрицательный опыт) * мнение уважаемых тобой людей. И опыт именно индивидуальный.
Кто на чем больше писал (потому что нравилось) то и будет выбрано.
4) при увеличении сложности он так или иначе появляется.

Поэтому, в силу меньших затрат и рисков, заказчик чаще выбирает Java
про риски серьёзных доводов я не услышал. Затраты....хм, тут всё индивидуально и требует расчётов. Что дороже: платить большую зарплату программистам выбрав java или купить винсервер.

Реальным поводом выбора технологии может быть, скажем, отсутствие крайне важной библиотеки (например не было бы на .net ни одной ОRМ и нужно писать всё на SQL). Для каких-то проектов это может играть роль, но технологии тут не при чем.

Что дороже: платить большую зарплату программистам выбрав java или купить винсервер.
А дотнетчики типа бесплатно работают ?

типа 2800 против 3000 примерно расклад. Неужели сложно догадаться?

1) Даже первый пункт со стоимостью Windows сервера. Для серьёзной крупной компании это вообще не повод выбора. Там как правило зоопарк технологий и куча ранее купленных лицензий. Для мелкой есть различные программы типа бизспарк
Не всегда заказчики это Bank of America или Barklays. Есть и компании которым хочется сэкономить на MSSQL, WinServer, MSVS и еще на куче лицензий.
Критерий зрелости для этих технологий уже не столь уместен
Еще как уместен, я считаю что наличие спецификаций (java.net/...spec/pages/Home) и их реализаций это лучше чем просто набор фреймворков с документацией.
большую зарплату программистам выбрав java или купить винсервер.
Зарплаты примерно одинаковы и там и там.
Не всегда заказчики это Bank of America или Barklays. Есть и компании которым хочется сэкономить на MSSQL, WinServer, MSVS и еще на куче лицензий.
MsSQL Express — фришный. Ну и Мускул с Постгрессом никто не отменял (или они тоже платные?). Вместо ВинСервера — Линух с Моно.
Еще как уместен, я считаю что наличие спецификаций (java.net/...spec/pages/Home) и их реализаций это лучше чем просто набор фреймворков с документацией.
www.microsoft.com/...ls.aspx?id=7029
Зарплаты примерно одинаковы и там и там.
И на их фоне затраты на инфраструктуру уже не муляют.
www.microsoft.com/...ls.aspx?id=7029
Это спека только для C#, а там специфицирован весь технологический стек

Подумай сам: как бы Ксамарин умудрился адаптировать ASP.net и ASP.net MVC, если бы по ним не было спецификаций? У MVC вобще код открыт.

Покажи мне ее. А так же для entity framework, IILS, ADO.NET драйверов и вебсвервисов.

Вот по ASP.net http://msdn.microsoft.com/...y/ee532866.aspx. Я могу поискать остальные, если тебе очень хочется, но сначала ответь, зачем вообще тебе спеки?

Это просто дока, по ней ты не построишь свою имплементацию которая будет работать также как и родная MS’овская.

Мигелюшка успешно построил. Наверное там и другие есть, но нужно рыться в ДевелоперЦентер, а мне лень.

www.ecma-international.org/...ds/Ecma-335.htm — Вот стандарт по самому CLI. Если реализовать свой VM на основе стандарта, то в теории так же можно выполнять другие .Net сборки\фреймворки на нём же. Xamarin в общем-то делает тоже самое. После просто проверяет совместимость существующих фреймворков под свою реализацию CLI. Другой вопрос, что часто создатели этих фреймворков не парятся про такие вещи и напрямую используют WinAPI\Com\etc, что убивает идею простого переиспользования под mono.

Asp.net mvc висит целиком и полностью на asp.net-е. И насколько я помню, в Mono просто используется та же сборка System.Web.Mvc без портирования. Та же самая что и под виндовым .Net. Сырцы обоих Asp.Net MVC и EntityFramework открыты под Apache 2 лицензией, и Ксамарин их же и использует.

У MVC вобще код открыт.
Вообще-то уже весь FW открыли

если у вас есть аргументы, чтобы доказать, что причина выбора между .net и Java (именно ими) не в головах архитекторов (каких-то других людей, кто влияет на решение) и их личного предвзятого отношения к технологиям, а в чём-то другом, то я готов согласиться(переступив через себя) со всем остальным доводами.

P.S. Бывшие коллеги перешли в новом проекте на питон. Тащится один архитектор-техлид (меньше всего пишет код), когда выбирает новую либу. Остальные уже скоро год, как плюются кровью (и от поголовного оупенсорса в том числе).

Универсального ответа нет, все зависит от контекста, например в компании уже используется куча продуктов от MS, она может участвовать в партнерской программе МС, то им нет смысла писать новый продукт на Java. Таких примеров могут быть тысячи, и выбирать стек следует отталкиваясь от нужд компании, а не предпочтений одного из сотрудников.

Остальные уже скоро год, как плюются кровью (и от поголовного оупенсорса в том числе).
Это потому что либы пайтона разрабатываются всякими хипстерами с гитхаба.
один архитектор-техлид
Дайте угадаю, у него года 4-5 опыта или он просто гик/хипстер/поху*ист.

нет не угадали вообще. Опытный(10+) взрослый нормальный инженер. Просто что-то ему понравилось.

ну так значит выгодно иметь лицензии и скидки от MS и плечё не только из сообщества но и тех, кто кошельком отвечает.
Я общался на конференции с директорами по айти крупных компаний и банков оказалось, что там везде зоопарки. И одна из основных проблем, кстати, это работа этих зоопарков. Так вот они расскажут и про джаву и про .net вам столько г...на, что потом ни один продажник не продаст свой продукт. Поэтому негативные выводы большинства адептов джавы, как правило, надменны и принебрежительны по одной лишь причине — они знают MS стек значительно хуже. А новое требует изучения. А мозг не любит это делать и сопротивляется. «Блин, что за фигня?! На джаве я бы это за 5 минут сделал» — вот и весь диалог со своим эго. А дальше это можно завернуть в любую обёртку, хоть требования «дайте мне спеку, говоря я вам!» хоть «.net не кросплотформенные» (хотя это нефига не правда, но признавать это не выгодно)

Есть и компании которым хочется сэкономить на MSSQL, WinServer, MSVS и еще на куче лицензий
И отдать сэкономленные деньги в 5-кратном размере за услуги джава-архитекторам и программистам :)
И отдать сэкономленные деньги в 5-кратном размере за услуги джава-архитекторам и программистам :)
и спать спокойно, не опасаясь детёнышей Гейца

Если у заказчика продакшен и оперейшн и так на виндах, то выбрать дотнет по идее весьма логично. Да и вообще интеграция дотнета с остальными продуктами из майкрософта должна бы по логикей вещей быть очень и очень.

Отлично сказано, как человек который вместе с заказчиком плотно изучали все риски выбора стека плюсую.

Сам предпочитаю Java. Хочу добавить такую мысль: Java программистам не выгодно, чтобы NET загнулся совсем. Пока есть конкуренция — развивается Java. Если не будет NET — то Java перестанет активно развиваться.

Джаверам чем хуже — тем лучше.
Пусть платформы воюют и развиваются.

«Джава», «активно развиваться» — нет ли здесь противоречия?)

Пока есть конкуренция — развивается Java.
В джаве своя внутренняя конкуренция, .нет пофигу, а вот когда появляются всякие груви, скалы, котлины и т.д. они актовно начинают перетаскивать фичи.

Недавно узнал, что даже у языка С (без плюсов) есть «конкурент». В Швейцарии его заменяют на Component Pascal (наследник Оберона) — вершина творчества Н.Вирта в языках программирования (кстати, Гослинг идею виртуальной машины «стырил» у Вирта). Причем в некоторых ситуациях довольно таки неплохо заменяют — особенно в системах реального времени (да и во швейцарских банках). Т.е. на нем пишут все — включая операционную систему, драйвера и т.п. Так что «пусть растут все цветы» — так интереснее.

В Швейцарии его заменяют на Component Pascal (наследник Оберона) — вершина творчества Н.Вирта

«В Швейцарии» в одном отдельно взятом вузе?

(кстати, Гослинг идею виртуальной машины «стырил» у Вирта

UCSD Pascal это 1978 и практически без Вирта. Forth, который в прямом и косвенном шитом коде делал то же самое без громких названий, это 1968.

Т.е., хотите в Швейцарию — учите Component Pascal? //чешет репу//

ИМХО, какой стек у компании ведущий — тот и выбирают. А основной стек может быть выбран как угодно, ну например: чьи продажники раньше дорвались до конторы или программистов на чём нашли.

а заказчику пофиг, ему важна совокупная стоимость владения и сроки. Бывает даже используют обе технологии, где какая удобнее. Но джавы однозначно больше.

При чтении данного опуса мне привиделись радуги единороги и работа с БД в два клика... Только я что то на соседнм .net проекте вижу не два клика а стену кода на sql в репортинг сервисе и кучу половых сношений связаных с деплоем и прочим. Вообще c#. Язык то клевый, просто инфраструктура и библиотеки сделана индусами для школьников.
Про цены на лицензии мы по молчим, кто покупал веб сферу плачет еще на подходе к цирку.

При чтении данного опуса мне привиделись радуги единороги и работа с БД в два клика... Только я что то на соседнм .net проекте вижу не два клика а стену кода на sql в репортинг сервисе и кучу половых сношений связаных с деплоем и прочим.

на мс действительно очень удобно строить слой доступа к данным, если использовать мс сиквел.
Linq2SQL требует минимум конфигураций, совершенно простой маппинг через атрибуты, поддерживает все наборы вплоть до lazy loading, eager множественный с кондишинами, не привязан к строгой доменной модели и структуре бд, в некоторых случаях дает возможность для отличных универсальных решений например завязать однотипные сущности на одном классе. Позволяет в случае необходимости просто обратится с прямым запросом через контекст доступа и вернуть результат сразу в виде коллекции обьектов класса со всем рефами и условиями добавленными для контекста. Интерпретируемость и отложенное выполнение с оптимизированностью данного ОРМ показывает хорошие результаты по производительности и дает возможность работать с базой через строготипизированные запросы linq со всеми вытекающими включая intellisense.
Репозитории для доступа к данным с этим ОРМ делать тоже одно удовольствие. Стандартный базовый доступ к данным через обобщенный строготипизированный абстрактный класс. Все специфика включая кондишины в проивзодных классах.
Да, если даже не говорить о ОРМ их концепция с датасетами и возвращаемыми множественными таблицами в готовую схему данных, тоже крайне удобно для разработчика аналитических приложений\отчетности и тому подобное.
Если и это не устраиваем, юзаем провайдеры от производителей бд и работаем через коннекшин\комманд пишем любые строго\слаботипизированные решения для общения с бд. Если времени с избытком, можем реализовать решение для интерпретации linq запросов через expressions trees в родной синтаксис любого удаленного источника данных.

По моему вы не поняли в чем проблема, перевожу для тех кто в фольговой шапочке :)
Проблема в инфраструктуре и анальнейшем вендор локе.
Причем на вендора извесного свой незамутненной простотой и пионерским задором в деле отстрела технологий и фреймвоков.

Выпадки в адрес реплики по поводу работы с бд в 2 клика явно не касаются этого.

то что вы написали тоже на два клика ни разу не похоже :)

Балки, как пожелаете, через expression trees и linq в классе представления сущностей даже не зная сиквела, все это интерпретируется в скл. В конце то концов, на дотнете работают решения от всех/большмнства поставщиков орм. Сейчас речь идет о простых решениях.

А почему тогда для балков .netчики используют NHibernate, а не Entity Framework?

Может быть, потому что не нашли вот этого github.com/...mework.Extended ?

Таки да, первый раз слышу. И как, годно работает?

Батч делит проверяли, работает. Батч апдейт пока не был нужен.

Речь не о ef, а о LinqToSQL , альтернативной простой ORM, которая заточена под мс. И для нее есть абсолютно открытый набор расширений linq2sql extensions. Так вот батчи реализованы и здесь. Update/Delete проверенны как на стороне приложения так и мс сиквел профайлера.

Сам Entity Framework не умеет работать с батчами, но есть расширения, доступные через nuget. В общем, нет большой проблемы, всё решается.

про вебсферу верно подметил :))

мне от тех цифр делалось так кисло и противно что я даже не помню примерный порядок цен.
Дороже 25К за ядро(подозреваю что это я оракловский порядок цен припомнил за БД а не вебсферовские расценки)? Или как там сейчас они считают?

Зависить от MS — в вышей степени стремно. На Яве же можно начать со всяких редхат/JBoss, потом переползти под Oracle (а то и на IBM раскошелится).

Зависить от Oracle — в вышей степени стремно. На C# же можно начать на всяких openSUSE/mono, а потом переползти на Windows Server.

Зависить от Oracle — в вышей степени стремно.
Так никто никогда и не зависел. Джава открыта.
На C# же можно начать на всяких openSUSE/mono, а потом переползти на Windows Server.
лол просто лол

От MS тоже никто не зависит, mono открыта.

mono открыта.

Если бы оно ещё действительно было дотнетом — было бы совсем хорошо.

Дело в названии? Я с ним работал, версии под МакОС и иОс — разговор отдельный, но виндовая и линусячая версия — ок.

Дело в названии?

Дело в том, что дотнет и моно — не одна и та же платформа, в отличие от.

Я с ним работал,

Рабочие проекты? Какого плана?

Дело в том, что дотнет и моно — не одна и та же платформа, в отличие от.
Если вы не признаёте стороних реализаций ВМ — то Джава в том же положении, что и дотНет.
Рабочие проекты? Какого плана?
Мобильные и пара сайтов.

Вообще-то, reference implementation это OpenJDK, который открыт и не зависит ни от кого.

Если вы не признаёте стороних реализаций ВМ — то Джава в том же положении, что и дотНет.

JVMы есть разные реализации одного и того же стандарта.

А моно не реализует на 100% стандарт дотнет.

И скорее всего не будет этого делать, бо Майкрософт свои стандарты любит привязывать исключительно к виндоус.

Оно реализует все языковые фичи, вплоть асинков из .net 4.5 (за исключением иОсной версии). Есть неувязки с WCF, но во всём остальном можно смело использовать.

JVMы есть разные реализации одного и того же стандарта.

Какой стандарт?

en.wikipedia.org/...f_ISO_standards
en.wikipedia.org/..._Ecma_standards
?

Какой сервер для сайтов использовали?

я когда-то в древности (год 2006-2008) тоже восхищался дотнетом — язык (даже тогда) сказка, либы — ну более менее, почти все «из коробки»
но потом углубился и разочаровался (нет, язык сам по себе очень неплох) но вот дальше и глубже:
— закрытые исходники (не изменяемые)
— «либы заточенные под туториалы» — т.е. пока идешь по гайду — все классно, шаг в сторону и начинается свистопляска . в принципе не большая проблема — копируешь нужный функционал из либы и правишь , если бы не закрытость
— короткий срок жизни либ — мало того что до ума не доводят так еще и бросают, очень неприятно
— «делфи» стайл — заточенность под гуи-дизайнеры. да, в определенном сегменте оно удобно, да и для студентов — накидал контролов на форму и уже «программист» , но когда идет чет сурьезное, где надо ручками — проблемы растут очень быстро

джава тоже не подарок — язык более «архаичный», нет многих синтаксических няшек, но за счет мультиплатформенности и большей открытости как-то более принята сообществом

— «делфи» стайл — заточенность под гуи-дизайнеры. да, в определенном сегменте оно удобно, да и для студентов — накидал контролов на форму и уже «программист» , но когда идет чет сурьезное, где надо ручками — проблемы растут очень быстро

1. Типичный снобизм, за которым нету никаких реальных аргументов, сколько кнопкой не «накидывай» — код все равно нужно писать. Не говоря уже о том, что только неадекваты могут считать, что делать UI без дизайнеров — лучше, чем с дизайнером. И то что человек работает с формами, никак не говорит о том, какой он программист.
2. Ничего такого там нету, есть System.Windows.Forms, и дизайнер в студии. Использовать эту сборку и создавать формы необязательно. Чушь не более.

Типичный снобизм, за которым нету никаких реальных аргументов
та лан. я лет пять с делфи проработал (а потом еще и года полтора с формс)
Не говоря уже о том, что только неадекваты могут считать, что делать UI без дизайнеров — лучше, чем с дизайнером.
согласен. говорить такое обобщенно неправильно. поэтому я написал про «сегменты»
Использовать эту сборку и создавать формы необязательно.
ну если в формс такое еще можно делать, то с асп.нет оно несколько жутковато выходит
ну если в формс такое еще можно делать, то с асп.нет оно несколько жутковато выходит

ASP.NET без WebForms (которые отличаются от WinForms), это тот же JSP. Нет никаких проблем писать смесь html + c# код.
ASP.NET MVC + Razor — форм нету вообще.

спасибо капитан
как вы правильно заметили даже мс со своим «асп.нет мвц» отказались от дизайнеров, т.е. они по вашей терминологии неадекваты :)

Не говоря уже о том, что только неадекваты могут считать, что делать UI без дизайнеров — лучше, чем с дизайнером

не отказалась, а дополнили инструментарий шаблонов для веба и дали возможность из чего выбрать. ну и asp.net mvc вполне совместим с веб-формами.

закрытые исходники (не изменяемые)
1. Уже давно нет
2. Вам часто приходилось править те исходники? Не, не third-party либу, а именно что-то из FW?
короткий срок жизни либ — мало того что до ума не доводят так еще и бросают, очень неприятно
Например?
«делфи» стайл — заточенность под гуи-дизайнеры
Это не MS. Это мейнстрим такой был тогда.
1. Уже давно нет
2. Вам часто приходилось править те исходники? Не, не third-party либу, а именно что-то из FW?
Если не изменяет память то МС «открывает» исходники под какой то анальной лицензией, которая позволяет ознакамливаться только, что исключает участие сообщества в прогрессе, как в случае с джава.
Если не изменяет память то МС «открывает» исходники под какой то анальной лицензией, которая позволяет ознакамливаться только, что исключает участие сообщества в прогрессе, как в случае с джава.
И? Какое это имеет отношение к проблемам, озвученным троллемтоварищем по имени proger? Я уж молчу про отношение к моим вопросам, которые вы процитировали
И? Какое это имеет отношение к проблемам, озвученным троллемтоварищем по имени proger? Я уж молчу про отношение к моим вопросам, которые вы процитировали
Тролль Владимир, очевидно что если исходники нельзя править и распространять патчи, то весь смысл в их правке пропадает, как и смысл твоих вопросов.
Владимир, очевидно что если исходники нельзя править и распространять патчи
1. Вы хоть читали ту EULA?
2. Править таки можно
3. Почему вы так упорно игнорируете вопрос насчет того, сколько раз в жизни вам нужно было что-то подправить из не third-party либ? ;)
1. Вы хоть читали ту EULA?
Читал, а ты читал? Что вычитал?
2. Править таки можно
Править таки нельзя: «The license prohibits all use of source code other than the viewing of the code for reference purposes.» referencesource.microsoft.com/...elicensing.aspx
3. Почему вы так упорно игнорируете вопрос насчет того, сколько раз в жизни вам нужно было что-то подправить из не third-party либ? ;)
Я тебе ответил уже.
Я тебе ответил уже
Нет. Ты так и не написал, сколько раз ты находил баги в FW и хотел их подправить. Только абстрактные фразы о том, что надо помочь коммюнити, а низзя.

Про баги ты тока счас придумал. И почему фразы про комьюнити абстрактные?

Про баги ты тока счас придумал.
Эт не я придумал, это до тебя ток дошло.
Ибо FW правят по двум причинам — баги\недоработки и расширение функциональности.

Очевидно, что у рядового стартапера\бодишопера вероятность первых правок возникает на порядок чаще вторых.

Я вот баги в чужих опенсорсных продуктах правил. Так что знаю.

За сим и спрашиваю — нужда в правке багов во FW возникала? Если нет — тогда вопрос о закрытости исходников снимаеццо.

И почему фразы про комьюнити абстрактные?
Потому что ты даже баги не правил, как видно. А за коммунити, которое что-то там хочет пропатчить, душа болит. Якобы.
т не я придумал, это до тебя ток дошло.
Для тех до кого слабо доходит, править баги в .нете безсмысленно, потому что ты с патчем ничего не сделаешь, лицензия не позволяет.
Очевидно, что у радового стартапера\бодишопера вероятность первых правок возникает на порядок чаще вторых.
Ты крайне странное существо, я вообще на .нете не программитую, как это снимает вопрос закрытости срцов?
Потому что ты даже баги не правил, как видно. А за коммунити, которое что-то там хочет пропатчить, душа болит. Якобы.
Мне за .нет комьюнити душа никак не болит, что совсем не запрещает мне констатировать факт его анальной защемленности по сравнению с джава комьюнити.
Ты крайне странное существо, я вообще на .нете не программитую, как это снимает вопрос закрытости срцов
Вопрос был безотносительно нета.
Вы вообще хоть в одном FW, отличающемся от трех мелких говнолиб, баги правили? Нужда была?
Мне за .нет комьюнити душа никак не болит, что совсем не запрещает мне констатировать факт его анальной защемленности по сравнению с джава комьюнити.
Так и запишем — аргументов нет, не в теме, но потрындеть хочса.
Вопрос был безотносительно нета.
Вы вообще хоть в одном FW, отличающемся от трех мелких гoвнолиб, баги правили? Нужда была?
В фреймворках нет, в некоторых гoвнопрогах, которые правда вполне на слуху — правил.
Так и запишем — аргументов нет, не в теме, но потрындеть хочса.
Ок, появятся аргументы кроме потрындеть — приходи
В фреймворках нет
Но кричишь на каждом углу как плохо, что нельзя подправить баги в FW

Ты троллишь, я только обратил твое внимание на то что код МС не опенсорс, а под анальной лицензией которая не позволяет правки. Хотя от меня ускользает сакральная разница в этом плане между либами и фреймворками, и почему мой пример должен что-то там глобально опровергать или доказывать.

я только обратил твое внимание на то что код МС не опенсорс
Ты упорно игнорируешь вопрос «и че?»
и почему мой пример должен что-то там глобально опровергать или доказывать.
Дык ты даже чужого примера не привел, из числа знакомых.

Значит никого из твоего окружения не волнует открытость этих исходников. По факту — абы потрындеть.

Ты упорно игнорируешь вопрос «и че?»
Я на такие вопросы даже как то стесняюсь отвечать, иначе ты еще подумаешь что я тебя за совсем тупого держу.
Дык ты даже чужого примера не привел, из числа знакомых.
Значит никого из твоего окружения не волнует открытость этих исходников. По факту — абы потрындеть.
А я «по факту» должен был еще и догадаться что ты и про моих знакомых спрашивал? Я как то у знакомых не интересовался патчат ли они фреймворки если честно. Но вот куча какого то народу контрибьютит: github.com/...hs/contributors
Я на такие вопросы даже как то стесняюсь отвечать, иначе ты еще подумаешь что я тебя за совсем тупого держу.
толсто
А я «по факту» должен был еще и догадаться что ты и про моих знакомых спрашивал?
По факту если человек сам не делал чего-то, в необходимости чего он пытается убедить других, то он хотя бы приводит пример оных действий из числа своих товарищей.
толсто
Не, ну я мого обьяснить, но как то неудобно окажется.
По факту если человек сам не делал чего-то, в необходимости чего он пытается убедить других, то он хотя бы приводит пример оных действий из числа своих товарищей.
Не всегда.

2. Вам часто приходилось править те исходники? Не, не third-party либу, а именно что-то из FW?
их же не было

приходилось изголятся с ildasm/ilasm попутно подглядывая в рефлектор

Например?
формс
их же не было
Багов, которые хотелось подправить не было?
Так и запишем — нужды править FW у анонимного тролля не возникло.
формс
Круто. Более общего ответа трудно было ждать, разве что целиком написать — FW
Так и запишем
пейсатель ? хотя еще рано, ваших осенью накрывает

а про баги, там бывало и похуже — один из прелестнейших случаев был когда пацаны налажали с наследованием форм и их контролов (webbrowser и toolчего там , что вместо менюшек-тулбарок) и не нашли ничего лучше чем просто залочить в system.design в нескольких местах
ну и фиксить не стали, так и бросили
как по мне это не баг, это диверсия была

и не нашли ничего лучше чем просто залочить в system.design в нескольких местах
sealed ?
работа с БД это вообще два клика
А чтро именно эти клики делают?

“sending emails”, “receiving emails” © IT Crowd

у Джава там куча лицензий и всякой хрени
Интересно было бы расскрыть тему, что за хрени?
Неужели на Java можно сделать то, что нельзя сделать на C#
Да, можно, но не из-за языка, а из-за намного более богатой экосистемы либ.

Я вот встречал ситуацию когда Большой Бизнес похерил МС стек из-за политики поддержки МС, типа мс скл сервер и виндовс сервер 2000 закончили свой жизненный путь в 2009-ом, и у Большого Бизнеса встал вопрос нужно ли переписывать все апликухи на новые фреймворки и мс скл каждые 8 лет или перейти на линукс и оракл и не париться следующие 25 лет.

Еще был случай в местном украинском холдинге. MS взвинтил стоимость лицензии на SQL Server до критической для них отметки. Сейчас ребята в панике пытаются мигрировать на что-то другое, но это уже большая проблема

Неужели в скл сервере нет обратной совместимости?

Вроде смотрели, в звязке t sql, dts, olap, reporting обратной совместимости не было.

похоже на бред. У меня спойкойно все мигрирует такая связка

Лол, похоже на бред, DTS вообще уже давно deprecated.

ну его заменил SSIS. не верю, что там нельзя было просто мигронуть.

Так «мигрирует» или «не верю что нельзя мигрировать»? Даже в доке написано что есть куча неподдерживаемых функций.

Меня удивляет вот это.

и мс скл каждые 8 лет или перейти на линукс и оракл и не париться следующие 25 лет.
Вы пробовали перейти хотябы на убунте с одно LTS на другой.
А єто один из самых дружественных дистрибутивов и переход на ЛТС нужно делтаь раз в 5 лет, а не 8. Я не знаток что там с ораклом и поддержкой больше 8 лет. Но я поигрался с версиями и ОЛАП и отчетов разных производителей в МС это наиболее безболезненно.
Попробуйте с версии 7 постгреса(10 лет назад 2003 год актуальный) на 9 мигронуть большой проект — косяки будут долго вылазить.
Любую технологию после 10 лет застоя не просто мигронуть на новые веяния. И врядли кто больше мс поддерживает свои продуты. XP он уже 12 лет поддерживают и еще год будут. Назвите компанию которая поддерживает продукты по 12 лет?

Зачем мне постгрес если Большой Бизнес использует оракл с бесконечным циклом поддержки?

Ну разве что там что-то то не сложнее SELECT * FROM.
А так, заходим на МСДН, набираем в поиске Deprecated Database Engine Features in SQL Server 20<номер версии> и наслаждаемся обширными списками чего они теперь не поддерживают. Причем местами жестко не поддерживают с бросанием исключений.

для этого есть режим совместимости с предыдущей версией.

А что мне именно сделать что бы все фичи мс скл 2000-го поддерживались в 2012-ом?

Да Мелкософт вроде честно открытым текстом признается
Compatibility level provides only partial backward compatibility with earlier versions of SQL Server.
technet.microsoft.com/...0(SQL.100).aspx

ужно ли переписывать все апликухи на новые фреймворки и мс скл каждые 8 лет

Нут конечно, не нужно. Лучше использовать свой старый г-нокод, и плевать на прогресс.

А если этот код хорошо отлажен и работает?

За 8 лет, он уже морально устарело.
Что-то типа, у нас не используется ORM, SQL прям в коде строчками, про CSS и JS — не, не слышали. Зато у нас оно все отлажено. Или, обслуживаем клиентов с терминала под DOS, без мышки, зато у нас все отлажено и работает! У нас база данных — разшаренный файл MS Access, зато у нас отлажено и работает.

А если оно справляеться со своими задачами?

К моменту устаревания в говно и разростания вширь и ввысь, оно уже не справляется со своими задачами. И допиливать егог становится очень тяжело и дорого.

я знаю компании в которых 20 лет софту и они испытывают огромнейшие проблемы с поддержанием и особенно с изменением согласно действующему законодательству потому чт оуже и программистов на таких языках не найдеш. Да и не знали 20 лет назад ни о веб доступе и прочих вещах. Так что 10 лет софту это уже много. Я в конце 90х мигрировал нескоколько систем с нереляционных СУБД на реляционные и переписовал так тогда им только по 10 лет быто. Сейчас таким системам по 20 лет. Сегодняшние «сеньеры» когда писался этот софт под столом проходили не нагинаясь ;) И врядли кто-то из них захочет изучать COBOL или FORTH$)

Вам не приходило в голову, что ПО пишется не для красивого кода и архитектурных изысков?

И да, одно дело, когда Вы переписываете код в ходе плановой модернизации (т.е. вас никто не гонит), а совсем другое — когда старый код не совместим с новыми технологиями.

Где в этой ветке что написано про код и архитектурные изыски?
Автоматическое решение таких проблем как SQL-инйекция, и валидация запроса во время компиляции, это красивости?
Лучшее масштабирование и производительность за счет обновления СКБД — архитектурный изыск?
Удобный UI, которые повышает производительность кассира, и не требует длительного обучения — тоже.

И да, одно дело, когда Вы переписываете код в ходе плановой модернизации (т.е. вас никто не гонит), а совсем другое — когда старый код не совместим с новыми технологиями.
Что это вообще за чушь?
Вас кто-то гонит совмещать что-то с новыми технологиями?
У вас то старое — отлажено и работает, то вдруг новые технологии вам давай,
к тому же вас ещё кто-то гонит, куда то. У вас проблемы с планированием?

Это форум разработчиков, или сборище зомби-луддитов?

Где в этой ветке что написано про код и архитектурные изыски?
Лучше использовать свой старый г-нокод
Лучшее масштабирование и производительность за счет обновления СКБД — архитектурный изыск?
Если оно не нужно — то да.
Удобный UI, которые повышает производительность кассира, и не требует длительного обучения — тоже.
Новый UI = переучивать ВСЕХ работников. Вспомните шок от 2007 офиса (хотя для освоения с нуля, он оказывался проще, чем предыдущий интерфейс).
Что это вообще за чушь?
Вас кто-то гонит совмещать что-то с новыми технологиями?
У вас то старое — отлажено и работает, то вдруг новые технологии вам давай,
к тому же вас ещё кто-то гонит, куда то.
у Большого Бизнеса встал вопрос нужно ли переписывать все апликухи на новые фреймворки и мс скл каждые 8 лет
Если вы не золотая рыбка, то стартовое сообщение ветки должны помнить.

Суть моего сообщения, чтоб не утруждать вас в следующем — обновление ПО с течением времени — это гуд. Обновление ПО под давлением (например, ваш код не работает с новыми версиями API) — всегда проблемно и может быть чревато багами, от желания побыстрее закончить.

Вас кто, то заставляет использовать новое API? Кто-то заставляет переходить на новые ОС? Да сидите с DOS, хоть 100 лет. У вас же все отлажено.

Не обижайтесь :) Когда нибудь и вы поймёте, что постоянно переписывать работающий код — не самая лучшая затея.

Работающий код со временем становится хреново работающим, ввиду того, что куча апдейтов, зафигаченных по древним, как говно мамонта, технологиям, работают вкривь, вкось, да еще и требуют кучу времени разработчика.

cleancoders.com — Обязательно посмотрите (не уверен, ести ли в открытом доступе). Там хорошо рассказывается о «давай-те всё с нуля перепишем!»

Нафиг мне ваш клинкодерс?
Вы хотите одним примером опровергнуть тенденцию того, что живой, развивающийся проект нуждается в смене технологий?

Нафиг мне ваш клинкодерс?
Шикарный подход :) Нет, вам оно ни к чему, что вы.
Вы хотите одним примером опровергнуть тенденцию того, что живой, развивающийся проект нуждается в смене технологий?
Живой, развивающийся проект нуждается в росте функционала и масштабируемости. А если к этому добавляется смена технологий по кругу, в зависимости от желания левой пятки тех. дира/архитектора/админа/вендора — это приводит к большим проблемам.

Смена технологий должна быть обоснованна только ростом нагрузки/новым функционалом. Остальные «причины» должны быть сведены к минимуму.

А если к этому добавляется смена технологий по кругу, в зависимости от желания левой пятки тех. дира/архитектора/админа/вендора — это приводит к большим проблемам.

Не знаю как там у вас, но по-хорошему технологии меняют в зависимости от потребностей.

Смена технологий должна быть обоснованна только ростом нагрузки/новым функционалом.
Вы вообще читали то, что я вам писал? Или ломиться в открытую дверь — ваш фирменный прием?
Да сидите с DOS, хоть 100 лет.
В банках сидят :(
Лучше использовать свой старый г-нокод, и плевать на прогресс.

Если не использовать свой старый г-нкод прийдется очень много чего выкинуть. Например, все ОС с ядром NT.

Я только за. Но нужно учитывать ограничения, и в случае с ОС, это сложнее чем с просто с бизнес приложением. Но все равно, обновляться нужно. Или что же, давайте IE6 пользоваться? Или Мозиллой 10 летней давности?

Я сильно сомневаюсь, что в твоем нынешнем браузере не висит код времен его самой первой бета-версии.

Речь шла об отказе от перехода на новые технологии и новый софт, а не об переписывании всего с нуля.

Именно об переписывании и шла:

нужно ли переписывать все апликухи на новые фреймворки и мс скл каждые 8 лет
конечно, не нужно. Лучше использовать свой старый г-нокод, и плевать на прогресс.

Майкрософт вообще любит выкатывать технологии без обратной совместимости.

Шутка дня. Если кто и поддерживает обратную совместимость то МС. Это одна из их фишек.

XNA — закрыт. Пока поддерживался — со совместимостью проблем не было.

Ок.

Майкрософт любит закрыть технологию (все равно сколько народу на ней сидит) и выкатить нечто принципиально новое (и не совместимое с километрами старого кода).

А с обратной совместимостью проблем нет.

Только провальные, вроде XNA и Silverlight. WinForms и ASP.net WebForms уже десятый год поддерживаются. К сожалению. А что, вы не в состоянии раз в пять лет подучить новый фреймвёрк? Тогда Джава не для вас.

Silverlight
А чем сирвелат провален?
А что, вы не в состоянии раз в пять лет подучить новый фреймвёрк? Тогда Джава не для вас.
В джаве как раз спринг + хибернейт намного дольше лидируют уже.
А чем сирвелат провален?
Ну можно вызверетиться на бинарную несовместимость с нормальным .net... Но на самом деле он просто появился позже чем надо. Все внезапно полюбили HTML5 + js и стали закапывать Флеш ну и Сервелат заодно. Я лично — против.

Принцип выбора технологии C# vs Java заказчиком ?
это выбор между проприетарной и открытой экосистемами.

По личному опыту могу сказать, что укоренившийся стереотип относительно нестабильной мс как платформы все еще имеет место быть. Ну и само собой кроссплатформенность. Скорость разработки, стоимость и тому прочее аргументы второстепенные. И да, веб формы уже в прошлом, если сравнивать с тем, до чего они довели свой мвц паттерн.

И да, веб формы уже в прошлом, если сравнивать с тем, до чего они довели свой мвц паттерн.
А у МС какой-то особенный «МВЦ паттерн»?

Мне сложно говорить об особенности, но легко об удобстве. Я могу расширять и подменять любое звено собственной реализацией, писать свои движки, в две строчки кода обеспечивать полный ИоС, здесь даже писать с# в переменную с хтмл и жс без какого-то особо замудрого синтаксиса можно. Да и простите меня, но за одну связку linq+lambdas я готов вступить за них по многим сомнительным моментам.

Мне сложно говорить об особенности, но легко об удобстве.
Я могу расширять и подменять любое звено собственной реализацией, писать свои движки, в две строчки кода обеспечивать полный ИоС, здесь даже писать с# в переменную с хтмл и жс без какого-то особо замудрого синтаксиса можно.
Да и простите меня, но за одну связку linq+lambdas я готов вступить за них по многим сомнительным моментам.
Вот вы привели еще один аргумент за джаву :)
Джависты отличают «паттерн» от «фреймворка».
С технической точки зрения часто замечал у дотНетчиков, что они не всегда понимают суть подхода, а часто приравнивают какой-то подход и конкретную реализацию в платформе МС.

Мвц это паттерн, я ничего не напутал, если вам охота придраться или спровоцировать новый холливар , я пас, можете самоутверждатся дальше считая, что джава программисты умнее или как это занудно слово.. , ах да. Методичней:) удачи вам :)

Мвц это паттерн,
Да, паттерн.
они довели свой мвц паттерн.
И посиму вопрос:
Что привнесли нового МС в этот паттерн?
Если ничего, то вы только подтвердили мое наблюдение:
они не всегда понимают суть подхода, а часто приравнивают какой-то подход и конкретную реализацию в платформе МС
------
в две строчки кода обеспечивать полный ИоС,
ИоС — это абсолютно независящая от МВЦ штука :)
------
ах да. Методичней:) удачи вам :)
От питонисты и прочие хипстеры не так уныло сливают. В общем слив засчитан.

Я же вам сказал, мне сложно говорить, что нового, но он удобный. Думаю, методист вроде вас не будет спорить, что у многих паттернов ооп есть свои вариации в реализации. Давайте я попробую перечислить пару интересных фич на дотнете , а вы скажите доступно ли это на джаве и разберемся есть ли в нем что-то новое, если вам это действительно интересно, а вы не просто решили позудить в ответ не мои реплики.

Я же вам сказал, мне сложно говорить, что нового, но он удобный
-А на джаве-, ну чтоб без холивара скажем, на питоне МВЦ менее удобен?
Давайте я попробую перечислить пару интересных фич на дотнете , а вы скажите доступно ли это на джаве
И это человек говорил что не хочет холиварить :)
Сразу отвечаю на ваш первый пункт:
Замыкания есть начиная с версии 1.1
-А на джаве-, ну чтоб без холивара скажем, на питоне МВЦ менее удобен?

у нас же сабж? или вы уже за азартом забыли даже в каком топике находитесь?)
Замыкания есть начиная с версии 1.1
зато нету linq.
да и вообще какое отношения языковые фичи имеют к реализации паттерна?

дотнет, простые базовые вещи, без заумных теорий.
1. Action results — полное и просто разграничение реализации результата работы контроллера и обработки результата получаемого ответа на запрос, путем сообщения намерений будь-то html, json, xml, file. все в рамках единого кода одного метода. По сути еще одна прослойка между контроллером и вью, которая берет на себя всю работу по взаимодействию.
2. Convention over Configuration. Минимум кода, максимум результата, простые соглашения в именовании для связывания роутов с контроллерами и вью. Из конфигураций только роуты, что производится добавлением в коллекцию одного обьекта аннонимного типа. А так же обратное связывание получаемых данных из html аж вплоть до коллекций сложных типов + произвольная расширяемость по все направлениям.
3. Наборы множественных view engines для обработки одного и того же запроса путем создания «цепочки отвественности».

зато нету linq.
Именно линкью нет, но есть куча подобных библиотек, например гуава.
полное и просто разграничение
все в рамках единого кода одного метода.
Кроме кучи базвордов еще и взаимоисключающие параграфы
2. Convention over Configuration. Минимум кода, максимум результата, простые соглашения в именовании для связывания роутов с контроллерами и вью. Из конфигураций только роуты, что производится добавлением в коллекцию одного обьекта аннонимного типа. А так же обратное связывание получаемых данных из html аж вплоть до коллекций сложных типов + произвольная расширяемость по все направлениям.
Так а чем именно это лучше чем в джаве?
2. Convention over Configuration. Минимум кода, максимум результата,
очень сильно не хватает смайла facepalm
Так а чем именно это лучше чем в джаве?
чем сперва слизанное, затем неправильно понятое, и в последствии соответствующе реализованное в привычном MS-стиле может быть лучше? ;) ну как вариант: ПиАр и продажники там лучше... были когда-то, с чем в принципе я не спорю
Именно линкью нет, но есть куча подобных библиотек, например гуава.
все бы хорошо, но linq это не только библиотека. :)
Кроме кучи базвордов еще и взаимоисключающие параграфы
сильный аргумент. вы бы еще из разных топиковы фразы выдернули и сказали, что взаимоисключающие.
все бы хорошо, но linq это не только библиотека. :)
Т.е. единственная крутость линккью только в том что это не библиотека? Ок.
сильный аргумент. вы бы еще из разных топиковы фразы выдернули и сказали, что взаимоисключающие.
Не понял мысли, что именно тебе не понравилось? Взаимоисключающие параграфы были об одном и том же, или я что-то пропустил?

вся поняли, вы не поняли.., не знаю как помочь попробуйте перечитайте еще раз, если много непонятных фраз обратитесь к толковому словарю.

Ну вот пусть вначале тпара тройка «всех» отметится, а потом поговорим, а пока мимо кассы.

или вы уже за азартом забыли даже в каком топике находитесь?)
А вы:
Принцип выбора технологии C# vs Java заказчиком ?
Ну так че засчитываем вам слив по поводу МВЦ?
1. Action results — полное и просто разграничение реализации результата работы контроллера и обработки результата получаемого ответа на запрос
Так вроде большинство джава-фреймворков так делают: СпрингМВС, Страйпс, Джерси, Плей2 и тд.
Часто это решают аннотациями (декларативно), что таки лучше чем вызов хелпера.
Convention over Configuration. Минимум кода, максимум результата, простые соглашения в именовании для связывания роутов с контроллерами и вью.
Кому надо, тот докручивает сам за 5-10 минут. От только для общего фреймворка, «встроенность» такой фичи — это недостаток, ибо иногда это очень неудобно.
Поэтому в основном таки используют или конфиги, или аннотации, что существенно увеличивает гибкость системы, но при этом не сильно усложняет введение новых людей в проект.
А так же обратное связывание получаемых данных из html аж вплоть до коллекций сложных типов + произвольная расширяемость по все направлениям.
Большинство современных веб-фреймворков.
-------
И снова к пониманию:
Вы понимаете что то что вы перечислили — это фичи фреймворков, а не изменения в паттерне МВЦ?
Вы понимаете что то что вы перечислили — это фичи фреймворков, а не изменения в паттерне МВЦ?

мы не говорим об имзенениях паттерна, мы говорим об реализации паттерна. Или это тоже не политкорректно с моей стороны? Готов называть это особенностями фреймворка, не испытываю по этому поводу неудобств.

мы не говорим об имзенениях паттерна, мы говорим об реализации паттерна.
Ваши слова:
Мвц это паттерн,
до чего они довели свой мвц паттерн.
Так вот: до чего же они довели свой __МВЦ паттерн__? То что вы сейчас привели — это всего лишь фишечки, которые не имеют отношения ни к «паттерну МВЦ», ни к «платформе дотНет/джава», и они, как я привел примеры выше, встречаются в очень разных фреймворках, на разных языках/платформах.

думаю, я понял что же вас так смутило. Вы наверное подумали, что слово «свой» подразумевает претензию на право собственности на концепцию. Нет, я это не имел в виду.
Фишечки, о которых мы говорим в данном случае не уникальны, но характерны для мвц, а значит вполне уместны для нашей ветки.

Нет, я это не имел в виду.
Продолжаете уныло сливать :(
Вы наверное подумали, что слово «свой» подразумевает претензию на право собственности на концепцию.
Меня смутило, то что по вашим словам «МС довели паттерн МВЦ».
Фишечки, о которых мы говорим в данном случае не уникальны, но характерны для мвц
Фишечки о которых мы говорим не имеют ни какого отношения к паттерну МВЦ, тот же «convention over configuration» использован для реализации свойств (аксессоры) в джава. Но реализованы в дотНет фреймворке с похожим названием.
И ключевой мой посыл:
замечал у дотНетчиков, что они не всегда понимают суть подхода, а часто приравнивают какой-то подход и конкретную реализацию в платформе МС.
вы подтверждаете каждым своим комментом.

Ок, фича с конвенцией была раньше, как это перечеркивает то обстоятельно, что в мс ее удобно видоизменили или даже просто применили в мвц? это факт, а не ваши умозаключения, что это не имеет к мвц никакого отношения, как и остальные доводы. Про ваш *подход и реализацию мс*вообще молчу, если я уже сколько сообщений подряд пытаюсь донести, что не претендую с решениями от мс на уникальность или идеологическое первенство) себе доказали, ок, можете еще пару раз повторить, судя по всему это вам моральное удовольствие доставляет, не меньшее чем мне наблюдать за этим. :)

Ок, фича с конвенцией была раньше, как это перечеркивает то обстоятельно, что в мс ее удобно видоизменили или даже просто применили в мвц?
Ок, сойдесмо на том что вы абсолютно некомпетентны (не отличаете паттерн и фреймворк) и уныло сливаете.
... А жаль, так надеялсо что вы начнете заливать про МВВМ :(

Ну тогда может успокойтесь уже? Столько что-то доказывать некомпетентому человеку, разве это к лицу такому осведомленному профессионалу:) побоялись бы за свою репутацию.

Action results — полное и просто разграничение реализации результата работы контроллера и обработки результата получаемого ответа на запрос, путем сообщения намерений будь-то html, json, xml, file. все в рамках единого кода одного метода.
эхх, это и есть разнесённый Application Controller + Two Step View (более подробнее — здесь

и попытка выдавать классику экосистемы Java PoEAA под © майкрософта как раз и является тем самым «очень удобным фреймвёрком» ;)

здесь только моя аргументация, на тему почему паттерн мвц в реализации мс так мне удобен и мои попытки с Богданом выяснить есть ли в нем какие-то особенности.
Я даже не знаю, что там пытаются вам впарить недобросовестные менеджеры от мс. Судя по тому как вы их не любите, явно что-то не совсем хорошее)
Вообщем, здесь нету попытки отстаивать первенство мс в их решении.

Тезка, вам пытаются пояснить, что паттерн MVC — это, не более, чем схема распределения ответственности между тремя сущностями — моделью, контроллером и представлением.

Все остальные удобства, которые вы перечисляете, относятся к фреймворку под названием «ASP .NET MVC» — вероятно, наличие букв MVC в названии и приводит к путанице между понятиями «паттерн» и «фреймворк»

Что привнесли нового МС в этот паттерн?
ну не привнесли, а позаимствовали для windows forms и соответствующе распиарили, и правда не MVC, а MVP только, который для чисто виндовс.форточек оказался более удобным за счёт IoC в «ядерном принципе» этого паттерна, а так же более явно говорил, что нужно делать, и как разбивать лейеры приложения (с чем все МС-адепты, выросшие на Document-View компонентах библиотеки MFC (более полно, весь «гениальный» замысел архитектором МС того времени, раскрывается например здесь, ну а что, верх абстракции: Однодокументный Интерфейс-SDI и Многодокументный Интерфейс — MDI... кому нужно что-то нестандартное пусть читает майкрософт гайдлайны и не выпендривается, понимая, что остальное от лукавого или не сдаст экзамен на MCSD), самостоятельно ну ни как не могли справиться, и только те из них, кто попутно работал на два фронта — .NET и Java, разжевывали коллегам, как оно должно быть, и что вообще это за зверь такой — «Проектирование» и какие Методологии в его процессе используются).
Однако, как говорилось выше — не привнесли, а позаимствовали, щедро добавив брэнд «.NET» к концу, тем самым и получив свой фирменный «MVP.NET» который лёг в основу всего этого «удобного» фреймвёрка. А позаимствовали, кстати, у этого дядьки, который, будучи таки жаббером, подумал, что как-то так будет более удобней (ему абстракций никогда не хватало видите ли), но это уже другая история.

Однако, справедливости ради, вынужден уточнить, что тот самый MVC — всё-таки не является тем самым Паттерном, но ровно до тех пор, пока понятия «Архитектурный принцип» и «Паттерн проектирования» для вас всё-таки разные вещи.
Суть в том, что что б не запутаться в абстракциях и в конечном итоге увидеть конкретику, было решено называть более локальные и менее абстрактные принципы, которые с одной стороны, явно подлежат разделению на три фундаментальные группы: Порождающие, Структурные и Поведения (Поведенческие), а с другой — одновременно удовлетворяют разделению на: Уровень Классов и Уровень Объектов, теми самыми «Паттернами Проектирования», когда же более общие, более абстрактные и состоящие из нескольких слоёв (уровень бизнес логики, уровень абстракции доступа к данным и т.д.), именовать «Архитектурными Принципами», чем MVC в принципе и является.

linq+lambdas
linq это ведь просто язык для работы с коллекциями. И у нас есть лямбды

Очень поверхностное суждение о линку , обычно характерное для людей, которые не до конца не понимают, что это такое. Но для джавистов и этого вполне достаточно, что бы сильно не утруждать в сложных контраргументация и не обманывать себя)

Ты крут, столько раздутых щек, наездов, базвордов, и при этом ноль информации.

Очень поверхностное суждение о линку , обычно характерное для людей, которые не до конца не понимают, что это такое
Вот сколько не смотрел на энтот ваш линкью, он почти 1 в 1 похож на HQL по синтаксису
И у нас есть лямбды

Если это — у вас есть лямбды. То у C# есть кроссплатформенность, за счет mono.

Таки нужно, есть заказы.

Игры? Нет, это делают на Юнити. А вот кросплатформенные мобильные клиенты — дело обычное. Сайты тоже бывают, но реже.

Принцип выбора технологии C# vs Java заказчиком ?
Или дело всё таки в цене ?
Дело в том что ваше приложение должно запускатсо под РХЕЛом в ВебСфере и работать с продуктами Оракл. Дело в том что пул разработчиков больше.
И никого не ипет шо абезянке из страны 3-го мира (Украина)
работа с БД это вообще два клика, всё удобно,
сам язык очень «сахарный»
и тд.
Суть в том чьи продажники добрались первыми:
— если МСовские, то все будет на их платформе
— если Оракла, ИБМ, РетХат, то продажникам МС придетсо сильно постаратсо.
Дело в том что пул разработчиков больше.
И никого не ипет шо абезянке из страны 3-го мира (Украина)
работа с БД это вообще два клика, всё удобно,
сам язык очень «сахарный»
++

Ой правда? Значить JetBrains для обезьян из Укрины софт пишет? И ORM тоже для них придумали? Ведь производительность труда и автоматизация — это г-но, да?

Ой правда? Значить JetBrains для обезьян из Укрины софт пишет? И ORM тоже для них придумали? Ведь производительность труда и автоматизация — это г-но, да?
Проблемы индейцев шерифа не ипут ©
Так вот ваша производительность (как разработчика) — это проблемы ваши и вашего менеджера, а не заказчика. А в Украине, Индие или Калифорнии вы находитесь — это так же не важно.
Ну а раз уж мы заговорили про ОРМ и ДжетБрейнс, то вы сами должны понять тут у джавы неимоверный перевес, спсыбо за дополнительный аргумент :)

Зомби-зелоту, что не скажи — все аргумент в его сторону.
Автоматизация и удобство в конечном итоге влияет на качество и время необходимое на разработку. И если его это не волнует — он глуп. Так как это его деньги и его реализация его идей, а не менеджера.

Автоматизация и удобство в конечном итоге влияет на качество и время необходимое на разработку.

Качество и время разработки — это конечный результат. Как менеджер этого достигнет — заказчика не волнует.

ASP.NET не боится нагрузок, эта технология смотрит на нагрузку как Перельман на миллион ! Аутентификация, авторизация, сохранение состояния перегружаемой страницы, гриды с автоматической привязкой данных, AJAX и прочие типовые вещи — встроены в ядро ASP.NET. Кроме того, архитектура классического ASP.NET является компонентно-ориентированной, то есть Web-страница представляется как форма, на которую можно кидать контролы и компоненты, подписываться на их события, а инфраструктура ASP.NET сама разрулит это так, чтобы у пользователя отрендерился нужный html + javascript, реагирующий на его действия таким образом, чтобы логика обработки этих событий исполнялась на сервере... Всё понятно, быстро, логично, удобно !!!

Лол, в джаве такого добра тупо навалом: gwt, jsf, zk, vaadin, и еще 100500 фреймворков.

Вы хотите сказать, что при переходе с проекта на проект в одной предметной области Java программист возможно будет вынужден разбираться с новой либой. В то время как дотнетчик каждый раз будет встречать знакомые функции и подходы. Тогда 100500 фреймворков сливают.

Ну если тебя это пугает, то да, джава не для тебя. Правда может оказаться как и сложное программироваие в целом. В больших системах основная сложность в внутренней логике, а не в том какой фреймворк юзается.
Хотя в .нете тоже вроде как успели наплодить подходов и веб фреймворков.

Та не чем уже можно испугать, ну разве что веерными отключениями электричества.

Ну тогда у тебя не должно быть проблем с обилием фреймворков, тем более что среди них победителей только пару штук, а с проигравшими сферический джава программист вряд ли встретится. Зато конкуренция, побеждает лучший, а не тот кого МС всучит.

Кто победители в той же нише, что и ASP?

основываясь в основном на мэйнстримном потребительском спросе, лично я нахожу, что PHP ;) разумеется, идеологически оставаясь на стороне Java в случае Java vs .NET, но с другой стороны, я не могу не замечать стабильность массовости спроса PHP-шной ниши. Разумеется, когда я говорю о PHP, я понимаю стэк из
php 5.4
PSR-0 — PSR-2
Zend 2 / Symfony 2 / Falcon PHP
и прочие ништяки, на которые не спешат переходить те самые олдскульные похапэшники ;)

Так же, лично я допускаю достаточно любопытное будущее Node.js и всего, что с ней связано, но пока для неё нет е-коммерс решений уровня Magento/PrestaShop, нишевость пыха вряд ли что-либо отожмёт в ближайшие года 3-4, но это ИМХО, опять же

Кто победители в той же нише, что и ASP?
Прямым конкурентом наверное есть jsf, классических mvc — springmvc, держать кучу логики на клиенте и писать на джаве — gwt + расширения(extgwt, smartgwt)
ASP.NET не боится нагрузок, эта технология смотрит на нагрузку как Перельман на миллион
тото пацаны из стековерфлоу переписали сайт в «пшп-стиле» :)
ну и кеширование в асп.нет уж очень коряво сделано (по сравнению с memcache и прочее)
Аутентификация, авторизация, сохранение состояния перегружаемой страницы, гриды с автоматической привязкой данных, AJAX и прочие типовые вещи — встроены в ядро ASP.NET. Кроме того, архитектура классического ASP.NET является компонентно-ориентированной, то есть Web-страница представляется как форма, на которую можно кидать контролы и компоненты, подписываться на их события, а инфраструктура ASP.NET сама разрулит это так, чтобы у пользователя отрендерился нужный html + javascript, реагирующий на его действия таким образом, чтобы логика обработки этих событий исполнялась на сервере... Всё понятно, быстро, логично, удобно !!!
да. для приложений с 5 табличками и десятком формочек
тото пацаны из стековерфлоу переписали сайт в «пшп-стиле» :)

Стековерфлоу написан c ASP.NET MVC, а следовательно, никакого PHP-стиля там нету.
Но даже если писать на ASP.NET в PHP-стиле (просто вставлять куски C# кода в разметку),
работать с этим будет в разы приятней, чисто за счет языка.

PHP-стиле (просто вставлять куски C# кода в разметку),
вообще-то пшп стиль это мвц+шаблонизатор+орм
ничего не напоминает ? :)
вообще-то пшп стиль это мвц+шаблонизатор+орм
Херасе! Это 99% веба работает в «пхп стиле». :)
Обычно под «пхп стилем» подразумевают как раз смешаную разметку и код с прямыми запросами к БД.
Обычно под «пхп стилем» подразумевают как раз смешаную разметку и код с прямыми запросами к БД.
более десяти лет назад так и было (аналогично jsp и asp) , но время то не стоит на месте — в аспе появились слова «.нет» и «мвц», джава тоже не отстает , ну и пшп разработка давно изменилась

У меня, почему то, подозрение, что вы крупных проектов на Формах не делали. Это в МВЦ всё просто, понятно, быстро и удобно, а на формах бывает такое, что волосы встают быдом.

Аутентификация
 — да, все её используют, даже не задумываясь что она подверженна Session hijacking, так как привязки в IP там нету. А в куке хранится зашифрованный userName. Если потом вдруг утекает machineKey, с помощью которого она шифруется, то кука элементарно дешифруется, пишется любое имя пользователя, шифруется назад, и вот ты залогинен уже под другим пользователем.
авторизация
это вы о web.config-е и разграничении прав на его основе? её полезность очень быстро теряется при динамических страницах, аля CRM
сохранение состояния перегружаемой страницы
, это вы о ViewState? вообще спорная штука, особенно когда она занимает 30-70% от всей страницы при неграмотном её использовании.
гриды с автоматической привязкой данных
 — ага, шаг влево\вправо, и идёт postback на сервер. на клиенте грид толком ничего не умеет, всё идет на сервер.
Ajax
, это вы о UpdatePanel-и? еще одно странное наследие. к сожалению многие не парятся деталями её работы, и просто кидают её на форму, и набивают контролами. Никто не думает что она постоянно получает большие куски html на каждый чих пользователя, вместо использования темплейтов для биндинга на клиенте и ajax-а для его заполнения. Что у неё есть Conditional mode. Что она тянет за собой большой пак javascript-а.
Кроме того, архитектура классического ASP.NET является компонентно-ориентированной
Вы многое пробовали переопределять\заменять? да, некоторые вещи можно подменить своими, со своей реализацией, но очень многое скрыто за internal кодом, без права наследования\переиспользования. Простейщий пример получение mime типа по extension-у файлу. в Asp.net есть статик клас со списком самых популярных mime type-ов. Но само собой он internal, и его использовать нельзя.
Membership provider — еще один ужас. Большой костыль, и чтобы заставить его работать нужно переопределить пачки методов, некоторые из которых могут быть даже не нужны. И все ради того чтобы использовать LoginControl и пару других контролов. Причем стандартный SqlMembershiprProvider дико ограничен, и расширению не поддаётся в принципе.
Session state — отлично, хорошая вещь, только многие даже незнаёт что обработка одной страницы лочит сессию, и в один момент времени для пользователя обрабатывается только одна страница из-за этого лока. А о SessionStateBehavior-е многие вообще незнают.
Начальные версии asp.net web forms а обрабатывали запросы только на сервере, и о клиентском коде совершенно не парились

Вся идея WebForms как по мне это плохое наследие десктопа. MS пошла лёгким путём, есть WinForms с дизайнером форм, событийной моделью, и они целиком и полностью перенесли её в веб, чтобы было проще тем кто приходит с WinForms разработки. Тот же дизайнер, те же события, близкий worfklow. Но ведь это веб, а не десктоп. и не всегда такая модель подходит сюда.

Asp.net mvc фреймворк в этом плане более удобен, он позволяет управлять рендернигом, он расширяем изнутри засчет IoC-а, у него нету наследий прошлого от десктопа.

Не поймите меня не правильно, asp.net неплохая вещь, при её умелом использовании. она из коробки даёт много всего, но многие используют это все даже не задумываясь как оно работает, и потом на такие приложение монстрячие приложения страшно смотреть.

ASP.NET не боится нагрузок, эта технология смотрит на нагрузку как Перельман на миллион
- честно говоря смешно. конкретная нагрузка зависит от конкретного приложения и того как оно написано, что оно использует, какая база, ORM, caching layer, etc. сам фреймворк для этой обеспечения нагрузки особо ничего не делает

Видно что не первый год в теме :)

да, есть такое. уже успел насмотреться на упование на «всемогущий» asp.net-а без понимания того как оно работает :)

— да, все её используют, даже не задумываясь что она подверженна Session hijacking, так как привязки в IP там нету. А в куке хранится зашифрованный userName. Если потом вдруг утекает machineKey, с помощью которого она шифруется, то кука элементарно дешифруется, пишется любое имя пользователя, шифруется назад, и вот ты залогинен уже под другим пользователем.
Если заюзать https, то как именно можно сделать session hijacking?

https на весь сайт в принципе это решение, но не везде его используют к сожалению. и не всегда его достаточно.

если есть доступ к компу жертвы, можно просто взять сохранённые локально куки и использовать у себя.

Простой типичный пример: открытая WiFi сеть без пароля\либо wifi с WEP шифрованием. В наше время все еще встречается. Достаточно попасть с ту же сеть что и жертва, перехватить её пакеты, и логиниться под жертвой на сайте. в случае с http все очень просто и быстро. в случае с https сложнее — MITM атака плюс ARP spoofing, чтоб направить весь трафик жерты себе. И плюс прийдется помучаться с сертификатом.

И плюс прийдется помучаться с сертификатом.
Что значит помучаться? Без сертификата https действительно не нужен.

при MITM можно скопировать сертификат основываясь на сертификате нужного https сайта, но да, public\private ключи и сигнатуры будут отличаться, и браузер выдаст предупреждение о невалидном сертификате. Тут есть два способа:
1. добавить фейковый сертификат на машину жертвы, что проблемно
2. сделать редирект на http. То есть:
a. Жертва отсылает запрос на https сайт
b. с помощью MITM мы ловим его, и отсылаем назад http 301 на тот же адрес, но уже по http протоколу.
c. Жертва пересылает запрос опять но уже по http. Мы его ловим, устанавливаем соеденение с реальным https сайтом, и пересылаем запрос, получаем ответ, отсылаем пользователю.
d. Ну и дальше продолжаем быть проксёй. так как на C шаге кука уже в руках.

Второй способ очень сильно зависит от наблюдательности пользователя, заметит ли он переход с https на http, есть ли вообще http версия, и плюс от Secure параметра куки, который ставят весьма не часто.

Мысль собственно в том, привязка куки к айпи добавляет еще один уровень безопасности, и что это хорошая практика.

А вообще не. 2b не отработает, так как http 301 без корректного https соеденения мы не отошлём. так что 2 способ хреновый :)

Еще правильный сервер настроен так что реджектит хттп соединения на критичные страницы.

Підписатись на коментарі