Я бы выделил бизнес логику в отдельный слой, так как не всегда понятно, из скольких мест будут использоваться одни и те же бизнес-процессы. То есть контроллер — это всего лишь точка входа(причем очень часто для конкретной технологии).
Подобные восхваления можно написать практически про любой язык. Вот, уже упомянутый C#: ООП вместе с лямбда-функциями, dynamic, async / await и т.д. и т.п. Тут уж кто к чему привык)
С удовольствием бы прочитал статью как описание характера некоего персонажа. В хорошем развлекательном романе. А вот на Хабре хочется читать что-то более ёмкое, ясное и по-возможности техническое
Всё-таки предпочтительным вариантом для получения экземпляра является конструктор. Использование Service Locator оправдано только там, где без этого совсем не обойтись(Например, в фильтрах, но даже и там возможны варианты).
Ну почему уже который раз мне говорят, что я прям обязан изучать javascript. Есть много интересных языков и технологий, я и без ваших советов разберусь, что буду изучать, а что нет.
Мне нравится javascript, но не совсем понятно, почему я должен круто на нём писать, если я backend-разработчик(а там своих новшеств выше крыши). И если всё, что вы написали актаульно для frontend-разработчика, то при чем тут .Net?
Неужели существует Linq2Sql для MySql? Мне казалось, что Linq2Sql только для MS Sql, а в драйвере MySql провайдер для Entity Framework.
И мне вообще кажется, что изучать работу в .Net с MySql лучше не с linq…
Без FormData можно обойтись. Для Оперы 11.60 и выше это можно сделать без проблем(ну или почти без проблем). Кстати, как это сделать, я уже писал почти год назад
Использование nuget в данном случае привело к уже описанной ошибке, поэтому в моем случае(и думаю не только в моем) эффективнее использовать подправленные исходники.
И мне вообще кажется, что изучать работу в .Net с MySql лучше не с linq…