Очень непривычно и неудобно.
Дурацкий 3 колоночный макет.
Надо было слегка подновить стили, а не перефигачивать все…
Читал ленту только из-за нормального дизайна, теперь что то другое наверно выберу.
Хотел купить рюкзак — так и не нашел… Есть все Дорожные сумки, Кейсы, Портпледы, Портфели, Саквояжи и кофры, Сумки, Чемоданы, но где долбаный рюкзак? Поиск перекидывает на старый маркет:(
Зачем мне менять T4 темплейты, если я могу просто писать код?
Знаю. Использование технологии в промышленных масштабах, не означает, что она лишена недостатков.
Кстати, действительно, не подумал об использовании скаффолдинга в качестве инструмента для обучения.
Вот только матерому профи не нужен весь этот нагенеренный мусор. Профи знает что, как и где написать, чтобы все было красиво, оптимально и без боли.
Да, я адепт кастомного и добротных компонентов. В кодогенерации разочаровался еще в студенчестве. Полуфабрикаты не люблю, когда использую подобное никак не могу отделаться от ощущения, что если бы написал все сам получилось бы все проще, быстрее и надежнее.
Разница в том, что бутсрап это код который я не в коем случае не буду редактировать. Мне нужно просто прочитать инструкцию и использовать. А скаффолдинг это куча бесполезного кода который придется менять. Зачем? Я быстрее и качественней с нуля напишу.
Даже если поверить в тесты, что важнее в 20 раз быстрее или в 2 раза больше гемора при поддержке? Я ведь не пишу твиттер. Короче если и использовать Lucene то далеко не в каждом проекте.
1. EF — не люблю ормы использую максимум мапер, но на это тему я уже холиварил…
2. Scaffolding — бред. Еще ни разу такое решение не работало. Всегда надо что то кастомное. Сейчас рулят бутстрапы — по сути готовая верстка, знай себе клепай вьюхи да процедуры. В случае написания админки просто идеально. Например twitter.github.com/bootstrap/index.html
3. Ninject. Я использую unity, но с ходу не нашел существенных отличий.
4. NLog. Высоко нагруженный сайт — хороший повод написать велосипед:) Логирование должно минимально влиять на производительность. Т.к. на прошлом проекте средней нагрузки log4net стал причиной тормозов, я не пожалел пары дней и написал свое логирование с шахматами и монашками.
Хотя NLog обязательно испытаю на проекте с меньшей нагрузкой.
5. PagedList — да о такой штуке сразу думаешь когда переходишь с WebForms, но по сути саму идею пейджинга для таблиц пора выкинуть на помойку. Добротный поиск — вот, что нужно пользователю.
6. Lucene.NET — интересная штука, надо посмотреть. Но вряд ли бы я отважился добавить это в реальный проект. И уж совсем не понятно как это может сравнится с мощью sql сервера.
7. На счет AspNetMembershipProvider это вы зря — нормальное решение для малых и средних проектов. Да процедуры написаны под sql 2000 потому и выглядят как дерьмо мамонта. Но процедуры из вашего примера используются лишь для редактирования пользователей. А вот для авторизации как раз все неплохо оптимизировано.
8. ASP.NET MVC4 Web API — да похоже ребята опять что то крутое готовят.
Читал, так же еще в таких книгах обычно написано лучше медленный тест чем никакого:) Действительно все тесты не гоняю каждый раз, только связанные с фичей, однако билдстанция прогоняет при каждом коммите и шлет письма если че не так.
1. С рефакторингом помогают тесты. С версионированием ОРМ не помогает.
2. Только бизнес-уровнем думает аналитик. Мне приходится думать обо всем… бизнес -> sql это проще чем бизнес -> генератор sql -> sql
1. Жалеешь голову работай руками :)
2. Это гипербола.
3. Слышали:) интеграционные эффективнее всего хоть и действительно сложнее. Юнит-тесты полезны пожалуй только в тестировании сложных алгоритмов.
1. Да слово «просто» я зря применил, потому что все на самом деле сложно:) Если логика крутится вокруг большего количества данных, зачем таскать их сквозь слои? Гораздо удобнее работать с данными на месте, т.е. в БД
2.Не люблю абстракций, люблю когда все предельно детерминированно — такие приложения поддерживать проще и они надежнее. Да я стараюсь думать о дисках когда пишу на sql и еще об оперативной памяти. БД как раз то самое место где стоит подумать о производительности.
1. sql надо блин знать полюбасу:)
2. см выше
3. Если приложение редактор БД почему логика должна быть не в БД? Грош цена такому тестированию которое не учитывает всех слоев.
1. А как же печальные случаи когда в место 1 джоина делается 100 запросов по связанной сущности?
2. С# не включает в себя sql:) Бизнес приложения — это в большинстве просто редакторы БД, все крутится вокруг БД => бизнес логику лучше хранить в БД. ООП фишек лучше здесь избегать, нужен простой понятный код.
3. Да я понимаю что это грязный прием и с ним нужно очень аккуратно, но когда дырка в огне и люди бьют друг другу морды в очереди из-за завышенного уровня блокировки(реальный случай). Такая возможность приходится очень кстати.
4. Незнаю. Опять же придется думать какой же sql сгенерится. Зачем? Проще самому написать.
я разочаровался в ОРМах. ИМХО удобней процедуры + мапер + тесты.
1. Не надо думать какой сгенерится sql в итоге.
2. Процедура — это sql без ограничений.
3. Процедуру всегда можно пофиксить на проде без выката всего приложения.
4. Уходит целый слой кода.
5. Код ферст? Неверю
Дурацкий 3 колоночный макет.
Надо было слегка подновить стили, а не перефигачивать все…
Читал ленту только из-за нормального дизайна, теперь что то другое наверно выберу.
Хотел купить рюкзак — так и не нашел… Есть все Дорожные сумки, Кейсы, Портпледы, Портфели, Саквояжи и кофры, Сумки, Чемоданы, но где долбаный рюкзак? Поиск перекидывает на старый маркет:(
Знаю. Использование технологии в промышленных масштабах, не означает, что она лишена недостатков.
Кстати, действительно, не подумал об использовании скаффолдинга в качестве инструмента для обучения.
Вот только матерому профи не нужен весь этот нагенеренный мусор. Профи знает что, как и где написать, чтобы все было красиво, оптимально и без боли.
Да, я адепт кастомного и добротных компонентов. В кодогенерации разочаровался еще в студенчестве. Полуфабрикаты не люблю, когда использую подобное никак не могу отделаться от ощущения, что если бы написал все сам получилось бы все проще, быстрее и надежнее.
1. EF — не люблю ормы использую максимум мапер, но на это тему я уже холиварил…
2. Scaffolding — бред. Еще ни разу такое решение не работало. Всегда надо что то кастомное. Сейчас рулят бутстрапы — по сути готовая верстка, знай себе клепай вьюхи да процедуры. В случае написания админки просто идеально. Например twitter.github.com/bootstrap/index.html
3. Ninject. Я использую unity, но с ходу не нашел существенных отличий.
4. NLog. Высоко нагруженный сайт — хороший повод написать велосипед:) Логирование должно минимально влиять на производительность. Т.к. на прошлом проекте средней нагрузки log4net стал причиной тормозов, я не пожалел пары дней и написал свое логирование с шахматами и монашками.
Хотя NLog обязательно испытаю на проекте с меньшей нагрузкой.
5. PagedList — да о такой штуке сразу думаешь когда переходишь с WebForms, но по сути саму идею пейджинга для таблиц пора выкинуть на помойку. Добротный поиск — вот, что нужно пользователю.
6. Lucene.NET — интересная штука, надо посмотреть. Но вряд ли бы я отважился добавить это в реальный проект. И уж совсем не понятно как это может сравнится с мощью sql сервера.
7. На счет AspNetMembershipProvider это вы зря — нормальное решение для малых и средних проектов. Да процедуры написаны под sql 2000 потому и выглядят как дерьмо мамонта. Но процедуры из вашего примера используются лишь для редактирования пользователей. А вот для авторизации как раз все неплохо оптимизировано.
8. ASP.NET MVC4 Web API — да похоже ребята опять что то крутое готовят.
2. Только бизнес-уровнем думает аналитик. Мне приходится думать обо всем… бизнес -> sql это проще чем бизнес -> генератор sql -> sql
2. Это гипербола.
3. Слышали:) интеграционные эффективнее всего хоть и действительно сложнее. Юнит-тесты полезны пожалуй только в тестировании сложных алгоритмов.
2.Не люблю абстракций, люблю когда все предельно детерминированно — такие приложения поддерживать проще и они надежнее. Да я стараюсь думать о дисках когда пишу на sql и еще об оперативной памяти. БД как раз то самое место где стоит подумать о производительности.
2. см выше
3. Если приложение редактор БД почему логика должна быть не в БД? Грош цена такому тестированию которое не учитывает всех слоев.
4. Ох как у вас все розово
5. Это круто, тут мне нечего сказать я не пробовал код ферст
2. С# не включает в себя sql:) Бизнес приложения — это в большинстве просто редакторы БД, все крутится вокруг БД => бизнес логику лучше хранить в БД. ООП фишек лучше здесь избегать, нужен простой понятный код.
3. Да я понимаю что это грязный прием и с ним нужно очень аккуратно, но когда дырка в огне и люди бьют друг другу морды в очереди из-за завышенного уровня блокировки(реальный случай). Такая возможность приходится очень кстати.
4. Незнаю. Опять же придется думать какой же sql сгенерится. Зачем? Проще самому написать.
1. Не надо думать какой сгенерится sql в итоге.
2. Процедура — это sql без ограничений.
3. Процедуру всегда можно пофиксить на проде без выката всего приложения.
4. Уходит целый слой кода.
5. Код ферст? Неверю