Книги по проектированию взаимодействий с БД
Вообще, .NET, но можно и другое что-нибудь, основы уловить, потом специфику какую-нибудь может сам придумаю.Лучше забить на всё, что написано Microsoft-ом или про технологии Microsoft-а, и почитать про паттерны для Java. Из-за дебильной политики EEE все нормальные, годные паттерны в книгах для Microsoft-а описаны с каким-то своим, отличным от других языков и технологий видением: начиная с диких идей про Visitor и заканчивая требованиями плодить кучу документации для Agile (видимо, в Microsoft жопу нечем подтирать).
Интересуют первые же решения: как отделить представление от данных и т.д.Я не понимаю вопроса: при чём тут БД?
Я не понимаю вопроса: при чём тут БД?интересуют примеры примененных подходов именно при проектировании приложений БД.
интересуют примеры примененных подходов именно при проектировании приложений БД.Извини, я окончательно запутался.
Отделение представления от данных в моём понимании - задача более общая, не обязательно связанная с БД. Тебя интересует её решение или, допустим, как лучше всего организовать работу с ADO.NET?конечно более общая. Попытайся понять мои намерения целиком, это же видно из названия треда, например. Я планирую написать довольно большое приложение, будет работа с БД. Раньше ничего крупнее датагрида во все окно не писал, и то дело было еще в школе.
Технические вопросы типа что такое реляционная БД, как написать запрос и т.д. ясны, интересны книги/источники, где рассматриваются вопросы проектирования, какие-нибудь идеи, именно по отношению к интерфейсам к БД.
Технические вопросы типа что такое реляционная БД, как написать запрос и т.д. ясны, интересны книги/источники, где рассматриваются вопросы проектирования, какие-нибудь идеи, именно по отношению к интерфейсам к БД.
Тебя интересует её решение или, допустим, как лучше всего организовать работу с ADO.NET?общего решения не представляю себе, второй вопрос, конечно, поставлен как-то странно, но скорее он меня интересует, чем нет, конечно.
Очень полезно пораньше узнать в какую трясину ты влезаешь, описано тут:
en http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...
ru http://citforum.ru/database/articles/vietnam/
en http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...
ru http://citforum.ru/database/articles/vietnam/
Тебя интересует её решение или, допустим, как лучше всего организовать работу с ADO.NET?совет правильный, ADO.NET надо знать на зубок
общего решения не представляю себе, второй вопрос, конечно, поставлен как-то странно, но скорее он меня интересует, чем нет, конечно.
совет правильный, ADO.NET надо знать на зубокесли, конечно, хочешь всё понимать. Некоторые пишут приложения без понимания.
Попытайся понять мои намерения целиком, это же видно из названия треда, например.Да у нас тут часто возникает такая проблема: пишешь что-то очевидное для тебя, а другие этого понять не могут, например.
интересны книги/источники, где рассматриваются вопросы проектирования, какие-нибудь идеи, именно по отношению к интерфейсам к БДДва хороших источника в этом случае - это J2EE Patterns и GoF. Из паттернов достаточно ознакомиться со связкой DAO/DTO.
общего решения не представляю себеДопустим, отделение данных от представления - это паттерны MVC и MVP. Отделение данных от бизнес логики - это DAO и DTO. Работа с ADO.NET - паттерны Thread Pool, Command и DAO. Думаю, что книжку читать не обязательно; если нужно, могу расписать архитектуру более детально, с примерами из практики.
почитать про паттерны для Java.в разрезе БД это не самый лучший совет. У джава и джавистов детская болезнь под название излишняя объектно ориентированность. В разрезе БД это часто ведет к проблемам там, где их нет или они значительно меньше.
У джава и джавистов детская болезнь под название излишняя объектно ориентированность.Это у Microsoft-а детская болезнь под названием MainClass.
Допустим, отделение данных от представления - это паттерны MVC и MVP. Отделение данных от бизнес логики - это DAO и DTO. Работа с ADO.NET - паттерны Thread Pool, Command и DAO. Думаю, что книжку читать не обязательно; если нужно, могу расписать архитектуру более детально, с примерами из практики.вот, это отделение от бизнес логики как раз и интересно. С MVC и MVP я знаком, в некоторых местах пишу их, естественно, чаще урезанные версии. НО, было бы интересно сразу посмотреть как их применяют именно к проектированию БД, т.е. примеры, примеры, примеры, но именно в формате книги, т.е. где бы обсуждались сложности, плюсы/минусы применения к БД. Про DAO и DTO вроде не слышал. Где про это лучше всего почитать? Последнее более менее ясно, значит да, выяснили, у меня вопрос в проектировании бизнес-логики
Допустим, отделение данных от представления - это паттерны MVC и MVP. Отделение данных от бизнес логики - это DAO и DTO. Работа с ADO.NET - паттерны Thread Pool, Command и DAO. Думаю, что книжку читать не обязательно; если нужно, могу расписать архитектуру более детально, с примерами из практики.Вот он существенный недостаток недопроприетарных технологий — чтобы решить одну задачу — взаимодействие с БД, нужно изучить кучу паттернов, технологий, подходов, чтобы сделать это правильно.
тут нету правильно курсивом, просто если придумывать свои архитектурные велосипеды, есть занс зарыться через полгода программирования в одно ебало 
И мне кажется, допроприетарные технологии тут мало помогут Или как?
И мне кажется, допроприетарные технологии тут мало помогут Или как?НО, было бы интересно сразу посмотреть как их применяют именно к проектированию БД, т.е. примеры, примеры, примеры, но именно в формате книги, т.е. где бы обсуждались сложности, плюсы/минусы применения к БД.Увы, качественных книг с практическими примерами очень мало. Во всяком случае, я не видел ни одной действительно стоящей вещи про ADO.NET; да и вообще хорошая книга по разработке программного обеспечения - это редкость, ты и сам это должен понимать.
Про DAO и DTO вроде не слышал. Где про это лучше всего почитать?Про идею можешь почитать на сайте J2EE: DTO, DAO; но учти, что на самом деле картина намного проще, чем описывается там, потому что J2EE всё-таки достаточно убогая вещь.
Вот он существенный недостаток недопроприетарных технологий — чтобы решить одну задачу — взаимодействие с БД, нужно изучить кучу паттернов, технологий, подходов, чтобы сделать это правильно.Ты считаешь, что лучше плотно перемешать бизнес модель и доступ к данным? Чтобы уже через месяц нельзя было: отодрать SQL запросы от бизнес логики, перейти на другую БД, написать тесты для DAO или моделей данных, и так далее?
Суть в том, что используя данные технологии, если я захочу сделать велосипед, то у меня получится только самолёт, никак не меньше. Для самолётов, конечно, они хорошо подходят, но не всегда нужно строить самолёты.
А какая альтернатива "проприетарных"? Дадут ЕДИНСТВЕННО ПРАВИЛЬНЫЙ инструмент, которым ты решишь все проблемы? Ну так этот инструмент тебя заебет на первом же шаге, отличным от написанного в книжке.Все эти технологии надо изучать, чтобы знать различные подходы, и уметь скомбинировать так, как лучше будет для задачи. Зная различные подходы - ты просто расширяешь свое сознание.
Я собираюсь строить самолет 
ORM упрощает эту задачу, но не всегда в нужную сторону. Например, оптимизировать производительность если нет прямых запросов, уже труднее.
Суть в том, что используя данные технологии, если я захочу сделать велосипед, то у меня получится только самолёт, никак не меньше.Какие именно технологии? DAO и DTO? Это настолько простые и удобные паттерны, что их используют даже в высоконагруженных проектах. При их использовании у тебя скорее получатся тапочки вместо велосипеда.
ORM упрощает эту задачу, но не всегда в нужную сторону. Например, оптимизировать производительность если нет прямых запросов, уже труднее.Что касается ORM, то его стоит использовать разве что для простого data binding. Полноценная система, кроме оптимизации, приносит ещё много проблем. Сюда же можно включить: дедлоки, трудности при обновлении схемы БД, потенциальные проблемы с потреблением памяти, проблемы с ленивой загрузкой данных. А в качестве data binding ты получаешь те же DTO, вид сбоку.
DAO и DTO?
Что касается ORM, то его стоит использовать разве что для простого data binding.ты про самое интересное не говоришь. Как обновляются данные в БД в сложных случаях: когда какое нибудь бизнес понятие-объект (например, документ) представляет собой непростой граф C#-объектов (с вложенные друг в друга коллекции и т.д.)
Как обновляются данные в БД в сложных случаях: когда какое нибудь бизнес понятие-объект (например, документ) представляет собой непростой граф C#-объектов (с вложенные друг в друга коллекции и т.д.)Как они обновляются? Например, быстро и без дедлоков.
Например, быстро и без дедлоков.Это всё что ты можешь сказать на эту тему? Возникает предположение, что ты с таким структурами не работал.
Это всё что ты можешь сказать на эту тему? Возникает предположение, что ты с таким структурами не работал.Нет, это далеко не всё что я могу сказать на эту тему. И если честно, то мне как-то похуй, что у тебя там возникает.
Ребята, давайте жить дружно!
или хотя бы ругаться не во всех тредах, а в одном
хм, а я тот не читаю, там тоже они?
Да, и вообще development - арена "ипического" противостояния. Такая себе "странная история доктора -а и мистера -а"
Да, и вообще development - арена "ипического" противостояния.Где же ещё в 2011 году можно найти противников автоматического тестирования, которые пытаются утверждать, что оно не только бесполезно, но и вообще вредит. Эти разработчики, может быть, целый день писали код с использованием автоматических тестов и за это время, безусловно, смогли до конца оценить этот подход. И неважно, что во всём мире известные люди пишут статьи, блоги и книги про тестирование - они просто тупые, а вот на forumlocal - умные, совершенные программисты.
оно не только бесполезно, но и вообще вредитПо-моему, идиоту ясно, что иногда юнит-тесты полезны, а иногда наоборот. А у вас у обоих крайние упертые точки зрения :-)
По-моему, идиоту ясно, что иногда юнит-тесты полезны, а иногда наоборот.Если ты напишешь это в нужной теме, то я дам тебе развёрнутый ответ. По-моему, идиоту ясно, что нельзя строить какие-то утверждения просто от балды и нужно подкреплять свою точку зрения цитатами людей, авторитет которых признают в мире разработки программного обеспечения.
нужно подкреплять свою точку зрения цитатами людей, авторитет которых признают в мире разработки программного обеспечения.Если бы этот раздел назывался Religion, то возможно.
Но он увы Development, и тут всем нужны примеры кода, а мнения у всех авторитетных дядек разные.
Но он увы Development, и тут всем нужны примеры кода, а мнения у всех авторитетных дядек разные.Если бы ты почитал авторитетных дяденек, то заметил бы примеры кода.
Если бы ты почитал авторитетных дяденек, то заметил бы примеры кода.
Вот и скопипасть их, снизойди до нас презренных, проведи ликбез :-) Иначе зачем форум?
Вот и скопипасть их, снизойди до нас презренных, проведи ликбез :-)Поверь, если я начну копипастить Фаулера, то это выльется в то, что 95% писателей в этом разделе начнут его троллить; при чём для троллинга они вряд ли выберут действительно сомнительные моменты. На то их и 95%.
Когда у человека нет авторитетов, кроме себя самого, убедить его в чём-то не представляется возможным. Однако очень забавляет, что люди с умным видом говорят о вкусе сахара, хотя пробовали только перец.
копипастить Фаулераэту фамилию уже можно троллить
далеко не всем по вкусу его идеи и тонны воды в книгах
далеко не всем по вкусу его идеи и тонны воды в книгахЯ с этим не спорю, у Фаулера есть многие вещи, с которыми либо тяжело, либо невозможно согласиться.
Если тебя или ещё кого-то не устраивает Фаулер, то я могу точно так же сослаться на Брюса Эккеля. В книге "Философия программирования на Java" есть глава, посвящённая автоматическому тестированию. Выжимка оттуда аналогична выжимке из книги про Рефакторинг: тесты позволяют быстрее разрабатывать программное обеспечение, повышают его надёжность, облегчают рефакторинг и доработку.
Брюс Эккель тоже не устраивает? Тогда обратимся к Кенту Беку, но тут всё ещё жёстче: пропагандируется разработка тестов до написания кода. И, заметь, утверждается что в итоге проект будет сделан быстрее и кода будет меньше, чем при разработке вообще без тестирования.
Я ещё раз повторю: если человек не признаёт авторитетов кроме себя, то любое общение, любой спор с ним превращается в балаган. А в случае автоматизированного тестирования, которое иногда окупает себя только после нескольких месяцев активной разработки, ситуация ухудшается ещё и полным непониманием с практической стороны.
Да, но Макконелл нам завещал, что юнит-тестами ловится гораздо меньше ошибок, чем простым просмотром кода. И еще у них есть ощутимые минусы:
они замедляют процесс написания кода,
они требуют излишней оопизации кода
они подходят далеко не для всех жизненных ситуаций
они по объему больше самого кода
ну и юнит-тесты всё равно не отменяют необходимости интеграционных и системных тестов и ручного дебага.
Плюсы довольно очевидны, но далеко не всегда перевешивают. В каждом конкретном случае необходимость юнит-тестов должна быть обоснована, обоснование "дядя Вася в книжке пишет" плохое. Софт бывает разный, и очень часто дядявасина ситуация не совпадает с твоей конкретной.
они замедляют процесс написания кода,
они требуют излишней оопизации кода
они подходят далеко не для всех жизненных ситуаций
они по объему больше самого кода
ну и юнит-тесты всё равно не отменяют необходимости интеграционных и системных тестов и ручного дебага.
Плюсы довольно очевидны, но далеко не всегда перевешивают. В каждом конкретном случае необходимость юнит-тестов должна быть обоснована, обоснование "дядя Вася в книжке пишет" плохое. Софт бывает разный, и очень часто дядявасина ситуация не совпадает с твоей конкретной.
всё написанное можно переформулировать без потери содержания двумя фразами:
1) писать тесты зачастую нелегко, и это нужно уметь;
2) тесты не являются серебряной пулей
не?
1) писать тесты зачастую нелегко, и это нужно уметь;
2) тесты не являются серебряной пулей
не?
1) писать тесты зачастую нелегко, и это нужно уметь;На самом деле, самое важное это уметь различать ситуации, когда тесты окупают себя, а когда нет.
неНе, ну а как я буду демагогию разводить, если так коротко писать?:-)
Да, но Макконелл нам завещал, что юнит-тестами ловится гораздо меньше ошибок, чем простым просмотром кода.Мне кажется, ты путаешь понятия QA и ошибки в коде.
они замедляют процесс написания кодаЭто твоё личное мнение, и при том ошибочное. Кроме чтения/цитирования книжек, я вот уже четвёртый год постоянно практикую разработку с использованием тестов. Моя производительность при использовании тестов вырастает в 2-3 раза. Своим подчинённым я говорю: "начните писать тесты, и вы автоматически станете на уровень выше, как разработчики". И до сих пор не было ребят, ни студентов без опыта работы, ни достаточно профессиональных программистов, которые последовав этому совету не убедились бы в его справедливости.
они требуют излишней оопизации кодаМожно определение "излишней оопизации"? А то мне как-то даже возразить нечего на эту непонятную фразу.
они по объему больше самого кодаА вот сторонники TDD уверены, что кода в итоге получается меньше. И лично я склонен с этим согласиться.
ну и юнит-тесты всё равно не отменяют необходимости интеграционных и системных тестов и ручного дебага.
Это явно не является "ощутимым минусом" юнит тестов. И, кстати, функциональные тесты тоже автоматизируются.
В каждом конкретном случае необходимость юнит-тестов должна быть обоснована, обоснование "дядя Вася в книжке пишет" плохое.Плохое обоснование - это как раз обоснование одного человека или группы лиц, не подтверждённое книжками. Как правило это означает, что эта группа лиц учится только на своих ошибках и не имеет достаточно глубоких профессиональных знаний.
Софт бывает разный, и очень часто дядявасина ситуация не совпадает с твоей конкретной.
Безусловно, свой студенческий проект на коленке можно склепать и без тестирования. Мало того, может получиться даже очень хороший программный продукт, который может даже стать коммерчески успешным и приносить деньги. Автоматическое тестирование - это универсальный механизм, который позволяет улучшать итоговое качество любого программного продукта, независимо от ситуации.
писать тесты зачастую нелегко, и это нужно уметь;На самом деле, я пытаюсь донести мысль, что всё с точностью до наоборот: писать с тестами проще и быстрее, хотя доказать это мелкой задачкой ни у кого не получится. Код становится более понятным разработчику, отпадает необходимость постоянной интерпретации в голове, можно протестировать различные граничные случаи.
В частности, автоматические тесты окупают себя:
1. Если в проекте более одного разработчика.
2. Если проект длится более месяца.
3. Если в проекте есть сложная бизнес логика или много математических формул (в этом случае автоматические тесты окупаются вообще моментально).
4. Если практикуется рефакторинг.
5. Если разрабатывается проект, работающий в режиме 24/365; или требующий высокой надёжности по любым другим причинам.
всё с точностью до наоборотПроцитирую тебя:
Это твоё личное мнение, и при том ошибочное.Вообще судя по категоричности в высказываниях ты кровавый паладин TDD и не хочешь принимать наличие другой точки зрения.
Сам-то подумай, почему TDD не захватило мир? Миллионы мух ошибаются?
Можно определение "излишней оопизации"?
Ну например тесты предполагают использование стратегий чуть менее чем в 100% случаев. А иногда оч хочется сделать какой-нить статический класс и забыть про него.
свой студенческий проект на коленке можно склепать и без тестирования
Можно и не студенческий. Никто еще не умер от отсутствия тестов, хотя полное их отсутствие - это такая же крайность, как и TDD. Не все проекты поддерживаются годами. Не все проекты изменяются. Не во всех проектах изменение одного куска кода приводит к краху в другом куске. Не во всех проектах нужно хорошее покрытие тестами. Это очевидно.
Плохое обоснование - это как раз обоснование одного человека или группы лиц, не подтверждённое книжками
Ну ты точно то ли богослов, то ли в президиуме ВАК заседаешь. В книжках (а тем более в статьях и блогах) можно написать что угодно, и поэтому там встречается ересь. Очень часто их пишут кровавые фанатики. При этом хорошие авторы пишут, что ничто не является панацеей. Ты эти слова, видимо, пропускаешь :-)
Вообще судя по категоричности в высказываниях ты кровавый паладин TDD и не хочешь принимать наличие другой точки зрения.Я не сторонник TDD. Похоже, что ты стал спорить со мной на тему, в которой не разобрался, и которую совсем не знаешь. Или не прочитал и половину моих аргументов в этой и других темах.
Сам-то подумай, почему TDD не захватило мир? Миллионы мух ошибаются?
Ну например тесты предполагают использование стратегий чуть менее чем в 100% случаев. А иногда оч хочется сделать какой-нить статический класс и забыть про него.Чего? Каких стратегий?
Ну ты точно то ли богослов, то ли в президиуме ВАК заседаешь. В книжках (а тем более в статьях и блогах) можно написать что угодно, и поэтому там встречается ересь. Очень часто их пишут кровавые фанатики.
В книжках что угодно написать нельзя. Это понимает любой человек, который сделал две курсовые и защитил диплом. Чтобы не выставлять себя шутом гороховым, хорошие авторы перед написанием книги читают другие книги и статьи, после чего ссылаются на них.
При этом хорошие авторы пишут, что ничто не является панацеей. Ты эти слова, видимо, пропускаешь
Ты, видимо, вообще не читаешь, что я пишу. Ты случайно не бот Шурика?
Чего? Каких стратегий?Хочешь ты написать класс доступа к внешнему сервису. В простом случае забиваешь и пишешь статический класс, но для теста скорее всего понадобится написать затычку. См. тред рядом.
В книжках что угодно написать нельзя. Это понимает любой человек, который сделал две курсовые и защитил диплом.
Мне тьфу-тьфу это все удалось, однако я читал довольно много книжек, в которых ссылок либо нет вообще, либо очень мало. С книжками дело обстоит лучше, с непечатными интернет-статьями и блогами - хуже. Наличие кучи пруфлинков, кстати, не является стопроцентным показателем качества, вопреки ожиданиям.
Чтобы не показаться тебе совсем упоротым, скажу, что я более чем наполовину согласен с твоими пятью пунктами постом выше.
Ты случайно не бот Шурика?
Ты знал
Хочешь ты написать класс доступа к внешнему сервису. В простом случае забиваешь и пишешь статический класс, но для теста скорее всего понадобится написать затычку. См. тред рядом.Это не называется стратегией. В некоторых случаях это может быть IoC или Dependency Injection. Затычку придётся писать только на Си++, в Java или C# есть подделки. Никакого "излишнего ООП" я тут не вижу.
Мне тьфу-тьфу это все удалось, однако я читал довольно много книжек, в которых ссылок либо нет вообще, либо очень мало. С книжками дело обстоит лучше, с непечатными интернет-статьями и блогами - хуже. Наличие кучи пруфлинков, кстати, не является стопроцентным показателем качества, вопреки ожиданиям.
Все книжки, на которые я до сих пор ссылался, являются достаточно качественными. Если Бека ещё и можно обвинить в слишком жёстком подходе, то уж про Эккеля что-то плохое сказать сложно - его книжки являются действительно стоящими внимания всех разработчиков.
Затычку придётся писать только на Си++, в Java или C# есть подделки.Но для этого же тебе все равно придется убить статический класс и сделать общение через инстанс, нет?
Но для этого же тебе все равно придется убить статический класс и сделать общение через инстанс, нет?Я вообще стараюсь по возможности убивать статические классы. И ни я, ни мои коллеги не видят в этом "излишнего ООП".
Надо понимать, что юнит тесты только в очень жёсткой форме требуют отдельного тестирования каждой функции каждого класса. Автоматический тест может покрывать 100% кода по control flow и при этом тестировать сразу несколько классов и их взаимодействия. Хотя в случае жёстких юнит тестов выделять интерфейс из каждого класса тоже не требуется.
Ребята, давайте жить дружно!Только ящерицу не посылай.
Ну я к тому, что чтобы юзать тесты, код должен быть изначально на это рассчитан (вот например статических классов в нем не должно быть). А строить код с рассчетом на тесты несколько дольше, чем писать просто так.
А строить код с рассчетом на тесты несколько дольше, чем писать просто так.Это обманчивое впечатление: тестируемый код как правильно имеет более хорошую архитектуру, в следствие чего его легче дорабатывать, расширять и рефакторить.
Думаю, что книжку читать не обязательно; если нужно, могу расписать архитектуру более детально, с примерами из практики.Да, интересно. Опиши, как вы кверите базу, если требуются непростые SELECT динамические запросы. Как это выглядит из C#-а?
Опиши, как вы кверите базу, если требуются непростые SELECT динамические запросы.Что такое "непростые SELECT динамические запросы"? Мне кажется, что мы таких зверей не используем.
Что такое "непростые SELECT динамические запросы"?что-то похожее описано вот здесь Dynamic Search Conditions in T-SQL
http://www.sommarskog.se/dyn-search-2005.html
Сам-то подумай, почему TDD не захватило мир?Не знаю, насколько распространён совсем прям настоящий test-driven development, как в XP.
Но чётко прослеживается взаимосвязь (и в open source, и проприетарных - в том числе в упомянутых тут "оперднях"
): 1) в проектах, где есть автотесты, код значительно качественнее, чем там, где их нету.
2) все большие/сложные проекты пользуются автотестами в том или ином виде
динамические запросыможешь привести примеры, в каких общих задачах они требуются, кроме ad hoc reports?
я могу назвать одну задачу, но это будет неинтересно т.к. очень узкая/специализированная (есть у нас механизм, заменяющий partitioning в оракле, и без динамических запросов его трудно делать, да и не нужно)
что-то похожее описано вот здесь Dynamic Search Conditions in T-SQLЭто ты про SQL запрос в 90 строк? У нас таких нет, не было и не будет.
Это ты про SQL запрос в 90 строк? У нас таких нет, не было и не будет.т.е. у вас нет даже поиска (пользовательского, желательно расширенного)? странно...
можешь привести примеры, в каких общих задачах они требуются, кроме ad hoc reports?любые многовариантные запросы: в частности, поиск, особенно расширенный.
как частный случай поиска - фильтрация и сортировка записей, опять же особенно расширенные.
т.е. как только пользователям предоставляется хоть какая-то свобода, так сразу появляются километровые динамические запросы
зы
и с ходу я вижу мало областей, когда пользователям не нужен свободный доступ к данным
т.е. у вас нет даже поиска (пользовательского, желательно расширенного)? странно...Есть, но запросов в 90 строк мы не используем. Кроме этого мы ещё не используем хранимые процедуры и транзакции.
всё что ты описал и называется обычно "ad hoc reports" по-моему
довольно специфичная часть системы, ортогональная к остальной архитектуре
довольно специфичная часть системы, ортогональная к остальной архитектуре
Это ты про SQL запрос в 90 строк? У нас таких нет, не было и не будет.
Есть, но запросов в 90 строк мы не используем. Кроме этого мы ещё не используем хранимые процедуры и транзакции.
Не уж то не нашел авторитетов, которые это рекомендуют?
Не уж то не нашел авторитетов, которые это рекомендуют?Которые рекомендуют что, простите?
всё что ты описал и называется обычно "ad hoc reports" по-моемуспецифична? ну, если угодно, называй ее специфичной. Пусть ортогональна. Что с того? Она от этого менее ценна для заказчика?
довольно специфичная часть системы, ортогональная к остальной архитектуре
Не уж то
специфична? ну, если угодно, называй ее специфичной. Пусть ортогональна. Что с того?в теме "книги по проектированию взаимодействий с БД" она либо просто оффтопик, либо на крайняк узкая область, с которой нет смысла начинать
онаизвини, не понял "она" тут кто/что?
я вот уже четвёртый год постоянно практикую разработку с использованием тестов.это тогда когда вы работали над проектом полгода, и вас в один день всех уволили, всю контору?
Тебе не приходила мысль, что без юнит тестов может успели бы написать проект?
А супер качеством можно было бы заняться позже, когда проект уже показал бы себя?
это тогда когда вы работали над проектом полгода, и вас в один день всех уволили, всю контору?Шуреск, ты выставляешь себя шутом в каждой теме в девелопменте. Твои наезды, где ты пытаешься задеть самолюбие человека, достойны только школьника. Ты не умеешь аргументировать в споре. Ты выпендриваешься и считаешь себя крутым девелопером, хотя на самом деле ты просто обычный кодер. Ты даже не умеешь писать по-русски, что уж говорить о том, как ты пишешь на C#.
Тебе не приходила мысль, что без юнит тестов может успели бы написать проект?
А супер качеством можно было бы заняться позже, когда проект уже показал бы себя?
Шуреск, ты выставляешь себя шутом в каждой теме в девелопменте. Твои наезды, где ты пытаешься задеть самолюбие человека, достойны только школьника. Ты не умеешь аргументировать в споре. Ты выпендриваешься и считаешь себя крутым девелопером, хотя на самом деле ты просто обычный кодер. Ты даже не умеешь писать по-русски, что уж говорить о том, как ты пишешь на C#.т.е. мысль такая не приходила, а зря, надо извлекать уроки не только из книжек.
Твои наезды, где ты пытаешься задеть самолюбие человека
Ты выпендриваешься и считаешь себя крутым девелопером
Между прочим ты делаешь всё то же самое, что и Shurick.
Между прочим ты делаешь всё то же самое, что и Shurick.Возможно. Но я всё равно пытаюсь аргументировать свои мысли. Я же не просто назвал тебя студентом без опыта работы, а потратил некоторое время, чтобы хоть что-то тебе растолковать.
т.е. мысль такая не приходила, а зря, надо извлекать уроки не только из книжек.Нет, не приходила, потому что стартапы проёбывают не разработчики. Ты, конечно же, не знаешь этого, потому что участвовал только в разработке стандартных программных продуктов низкого качества.
Которые рекомендуют что, простите?использовать все возможности СУБД при необходимости, а не вводить на что-то строгие запреты.
стандартных программных продуктовты часто употребляешь слова, которые не понимаешь?
Нет, не приходила, потому что стартапы проёбывают не разработчики.хорошо не за что не отвечать
.Ты даже не умеешь писать по-русски, что уж говорить о том, как ты пишешь на C#.я так и думал, что ты гуманитарий
использовать все возможности СУБД при необходимости, а не вводить на сто-то строгие запреты.Я разрабатываю высоконагруженный проект. Если бы ты изучал мнения других людей, ты бы знал, что база данных и так будет узким местом. И знал бы рекомендации по правильному её использованию в этом случае.
Ты сейчас будешь выглядеть как консультант из Microsoft-а, насчитавший нам 80 операций в секунду на 2500 IOPS.
ты часто употребляешь слова, которые не понимаешь?Ты не понимаешь слова "стандартный программный продукт сомнительного качества"? Я тебе объясню. Судя по твоим весьма недальновидным сообщениям, ты за всю свою практику делал только программы, которые можно кратко охарактеризовать примерно следующим образом: кондовый тормозной бэкофис и сервер, который пыхтит от пяти одновременных пользователей.
я так и думал, что ты гуманитарийЛучше быть качественным гуманитарием, чем непрофессиональным программистом, не знающим своего родного языка.
Я разрабатываю высоконагруженный проект.До высоконагруженного life-а они доходят? Можешь привести пример? Обычно высоконагруженные проекты широко известны.
бэкофисне, не угадал
Может привести пример.
Очередная попытка потроллить после прочтения Job-а, где я сказал, что связан NDA по текущему проекту?
Обычно высоконагруженные проекты широко известны.Я участвовал вот в этих:
http://fotki.yandex.ru
http://video.yandex.ru
не, не угадалЯ и не гадал, я сделал общее описание твоей кодерской практики. Можешь считать это метафорой. Хотя ты вряд ли знаешь, что это означает...
Я участвовал вот в этих:это на чем написано?
http://fotki.yandex.ru
http://video.yandex.ru
это на чем написано?Это написано на Java, C++, XML/XSLT/JavaScript, Python, Haskell.
Это написано на Java, C++, XML/XSLT/JavaScript, Python, Haskell.т.е. скил по работе с C#-кодом это не демонстрирует. Только вот не надо говорить, что скилы универсальны, это не так, языки разные.
ага, шарп - это великий и особенный язык. Там все по-другому.
ЗЫ простите, не удержался
ЗЫ простите, не удержался
т.е. скил по работе с C#-кодом это не демонстрирует.Нет, это демонстрирует скил по работе с базами данных в высоконагруженных проектах. Которого у тебя нет ни на практике, ни в теории.
ага, шарп - это великий и особенный язык. Там все по-другому.еще один, который может оперировать только терминами "великий", "гений" и т.д.
ЗЫ простите, не удержался
зато проявился, кто мне ставит минусы
Нет, это демонстрирует скил по работе с базами данных в высоконагруженных проектах.В списке не было SQL-я, без него с базой работаете?
Которого у тебя нет ни на практике, ни в теории
Голословное утверждение, высосанное из пальца.
Нет, это демонстрирует скил по работе с базами данных в высоконагруженных проектах.в тех проектах видно, что база не очень сложная и бизнес логики не так много и она, скорее всего, хорошо выверена бизнес аналитиками. Бывают совершенно другие проекты.
В списке не было SQL-я, без него с базой работаете?В списке много чего не было, с базой работают с использованием SQL, но на нём не "написан" проект.
Голословное утверждение, высосанное из пальца.Голословное? Я сказал, что мы работаем с базой без запросов на 90 строк, без транзакций и хранимых процедур. Ты на это наехал. Я ответил тебе, что проект высоконагруженный. Человеку, у которого есть хотя бы теоретический опыт, всё сразу должно было стать понятно. Но ты продолжаешь задавать мне какие-то левые вопросы.
в тех проектах видно, что база не очень сложная и бизнес логики не так много и она, скорее всего, хорошо выверена бизнес аналитиками.Такой вывод мог сделать только полный профан.
Ты на это наехал.читать научись, блин
читать научись, блинНаучись яснее высказывать свои мысли, даже когда тупо троллишь.
Такой вывод мог сделать только полный профан.а такой вывод мог сделать только тот, кто не работал с более-менее сложными базами при ограниченных ресурсах
а такой вывод мог сделать только тот, кто не работал с более-менее сложными базами при ограниченных ресурсахТы тупой бот: я тебе говорю про высоконагруженные проекты, а ты мне продолжаешь втирать про свой низкокачественный энтерпрайз.
Ты тупой бот: я тебе говорю про высоконагруженные проекты, а ты мне продолжаешь втирать про свой низкокачественный энтерпрайз.что не получилось выполнить ентерпрайз проекты с твоим стилем разработки и теперь в их адрес употребляешь уничижительные эпитеты?
что не получилось выполнить ентерпрайз проекты с твоим стилем разработки и теперь в их адрес употребляешь уничижительные эпитеты?Слава богу, в разработке энтерпрайза я никогда не участвовал. Зато теперь мне стало понятно, почему ты такой упоротый бот без чувства юмора. Оказывается, тебя надо жалеть и всячески тебе потакать, чтобы не вызывать у тебя приступов гнева, меланхолии и глубокой депрессии.
Слава богу, в разработке энтерпрайза я никогда не участвовал.т.е. ведешь спор о том в чем не разбираешься, как обычно
т.е. ведешь спор о том в чем не разбираешься, как обычноА ты разбираешься в энтерпрайзе, да?
А ты разбираешься в энтерпрайзе, да?достаточно того, что ты вообще не работал с этим.
достаточно того, что ты вообще не работал с этим.С чем я не работал?
Слава богу, в разработке энтерпрайза я никогда не участвовал.
проблемы ентерпрайз-разрабоки связаны не с какой либо спецфичностью девелопмента, а с организацией самой работы в корпоративной среде. Т.е. майку не важен опыт разработки "для ентерпрайз", важно понимание принципов работы корпораций.
проблемы ентерпрайз-разрабоки связаны не с какой либо спецфичностью девелопмента, а с организацией самой работы в корпоративной среде.по-моему там есть и те и другие, и, да, есть ситуации, когда вторые сильно перекрывают первые, и девелоперскими решениями там ничего не сделаешь. Но есть ситуации, когда успех/неудача проекта в руках девелоперов.
Но есть ситуации, когда успех/неудача проекта в руках девелоперов.Ути-пути, ты
наш герой!Ути-пути, ты наш герой!Да, это так. А у тебя посредственный уровень владения языком C#.
Да, это так.
А у тебя посредственный уровень владения языком C#.
Да, это так. А у тебя посредственный уровень владения языком C#.Господа, я уже запутался. Он так оригинально троллит или у него действительно столько нереализованных детских комплексов? А то мне уже страшно троллить его в ответ: чего доброго до него дойдёт смысл моих жёстких приколов, и Memorial пополнится ещё одним постом...
жёстких приколовНет уж продолжай, всем весело
чего доброго до него дойдёт смысл моих жёстких приколова без приколов можешь объяснить смысл твоих приколов?
а без приколов можешь объяснить смысл твоих приколов?Ты думаешь, он до тебя дойдёт?
Ты думаешь, он до тебя дойдёт?откуда я это могу знать?
откуда я это могу знать?Ну... ты же знаешь энтерпрайз.
Ну... ты же знаешь энтерпрайз.да, а еще я гений.
да, а еще я гений.Ты - великий разработчик,
Знаменитый Кодьдодыр,
Всяких сервисов начальник,
И сишарпа командир.
Если топнешь ты ногою,
Позовёшь своих солдат,
В форум-с-локалом толпою,
Быдлокодеры влетят
И залают, и завоют,
И ногами застучат,
И нам всем головомойку,
Неумелым, зададут!
Прямо сразу
Прямо сразу
В энтерпрайзный код на шарпе,
С головою окунут!
Оставить комментарий
Serab
Раньше ничего подобного не писал. Чего бы такого почитать?Вообще, .NET, но можно и другое что-нибудь, основы уловить, потом специфику какую-нибудь может сам придумаю.
Интересуют первые же решения: как отделить представление от данных и т.д.