Последние комментарии
Для меня эта страница - это удобный способ смотреть, что нового происходит в комментариях и сразу находить заметку, не заходя в админку. Думаю, она будет полезна и тебе.
Алексей
Михаил,извините что не в тему,но не могли бы прокомментировать взлом серверов NASA и про деятельность хакера TinKode.
VVS
Это вопрос был для ronin. Я просто не понимаю, какую библиотеку он имеет в виду. Я тоже использую ADO.NET(включая Entity Framework), но при грамотном проектировании всегда необходимо использовать прослойку для работы с ней(репозиторий), ronin утверждает что можно обойтись без этой прослойки. Вот мне и стало интересно, что же это за библиотека для доступа к БД.
X-Ray
Обновляю свой стационар редко. Последний собирал сам в 2008 г., купив комплектующие и корпус и БП с учетом небольшого апгрейда на всякий случай, т.к. иногда играюсь. В прошлом году увеличил оперативку с 2-х до 4-х Гб и поменял видюху на более новую, но не самую навороченную, в этом году добавил еще один винт, теперь 120 + 500 Гб. Пару лет назад поменял клаву, т.к. часто жена жаловалась на ее грохот, поэтому выбирал не брэнд, а стучал по клавишам в магазине и купил наиболее тихозвучащую. Вот и все, пока больше ничего ненадо. Монитор - старенький ЖК Philips 17" уже примерно 5-6 лет - работает прекрасно и менять не собираюсь.
Михаил Фленов
Что имеется ввиду под "она все умеет?". Я пользуюсь ADO.NET и она все, что должна уметь делать - умеет делать.
VVS
Стало интересно, назовите пожалуйста библиотеку для работы с БД которой вы пользуетесь и она все умеет?
ronin
по сути, если задуматься, то все эти библиотеки и есть классы, только написанные другими людьми, т.е. я отдаю себе отчёт что то о чём пишет Михаил это основа, теория, и так и должно быть, и так и написаны все эти библиотеки, это основа объектно ориентированного программирования, тут в принципе ничего гениального, возникает только вопрос самому писать эти прослойки или использовать чужой труд
для себя резюмирую
основные преимущества использования сторонних библиотек:
1. скорость разработки: ничего придумывать не надо, только подключай и пользуйся
2. качество: я всё таки думаю если человек целыми днями занимается разработкой компонентов доступа к данным, отображения данных и т.д. поболее меня соображает в этом вопросе, поэтому мне кажется что наступать на грабли на которые кто то уже когда то наступал не стоит, на это уйдёт много времени и не факт что ты преуспеешь
3. поддержка новых технологий: думаю здесь всё понятно, субд развиваются, интерфейсы тоже не стоят на месте, за всем не уследишь, и соответственно взваливать на себя непомерный груз не стоит
основные недостатки данного подхода:
1. зависимость от разработчика: тут всё понятно, проект умрёт, остановится развитие и твоего проекта и поддержка новых плюшек в библиотеке, при обновлении например СУБД
p.s. я соглашусь что можно применять подход предложенный автором как раз в небольших проектах, где объём такой работы будет невелик, а в крупных проектах думаю целесообразнее подключать сторонние библиотеки и не выдумывать, хотя если штат программистов велик и ресуры позволяют, то конечно независимость на первом месте
p.p.s ни в коей мере не пытался оспорить принцип описанный в теме, это на 100% правильно но в жизни всё немного сложнее и приходится выбирать, даже в теории БД есть такое понятие как денормализация :)
Михаил Фленов
Ни в коем случае не призываю изобретать велосипед. Я говорю только о подобного класса вспомогательных прибамбасах. Сторонние компоненты используют здесь без проблем и везде, но только небольшие и в основном отображения.
Все эти сторонние прибамбасы так же в ОБЯЗАТЕЛЬНОМ ПОРЯДКЕ нужно подключать через интерфейсы. Тогда вы сможете легко подменять код третих фирм легко и не принужденно.
ronin
вы что то путаете, при чём тут компоненты отображения данных и запросы, все специфические моменты реализуются в компонентах доступа к данным, а DevExpress только отображает эти данные
для этого существует огромное количество тех же компонентов, как платных так и бесплатных, ничего не надо придумывать
тут я с тобой не соглашусь, то есть ты призываешь бросить весь опыт накопленный другими людьми и начинать изобретать велосипед? лично для меня моё время дорого стоит, и я лучше заплачу 5000 рублей (представь какая это смешная сумма) за библиотеку компонентов доступа к данным и не буду париться по этому, поводу, сэкономлю МНОГО времени, которое я лучше потрачу на вылизывание кода и интерфейса, что бы программа написанная мною была как можно лучше, и я смог заработать денег, а не сидеть и открывать америку заново
может вы тогда ещё предложите VCL переписать заново, если уж пошла такая пьянка?
Михаил Фленов
В Канаде у меня не такой большой опыт работы с разными компаниями, но там, где я работал, ни кто не использовал библиотек типа DevExpress. Везде пишут ручками. И лично я считаю, что эти библиотеки вселенское зло, потому что при их использовании код получается мега привязанным к таким библиотекам и от них отказаться будет на много сложнее.

Алексей
Для начала надо определиться что же интересно делать конкретно взятому человеку применительно к индустрии разработки ПО.
На яве в основном пишут серверную логику ЕРП систем, процессинговых систем, корпоративных интрасетей. Не редко у компании внутренняя инфраструктура завязана на ява-платформу, а наружу смотрит сайт с милым красочным дизайном на друпале/джомле/джанге/etc. Т.е. зачем воротить сложное и неповоротливое там где справится php или python.
Т.е. если человеку интересно заниматься автоматизацией бизнес-процессов, то ява его выбор, но придется серьезно напрячся. Начать с ядра языка и основных библиотек (collections, reflections, swing, xml, etc.), потом изучить не менее важные вспомогательные библиотеки и технологии основной платформы (jndi, rmi, security api, etc. - это все обычно называют javase), затем взяться за javaee, а это та же джава + ворох технологий и спецификаций (ejb, jpa, springmvc, hibernate, jax-ws и т.п.). Короче, долгий путь. Две полки толстых книг, сотни часов и тысячи мануалов :)
На самом деле с шарпом пути дорожки расходятся на начальном этапе изучения ядра и основных библиотек. А языки похожи и очень простые, но не в них дело. Главное - это платформа и ее надо знать.
Так что муки выбора тут не безосновательны.
Лично я выбрал jee и oracle и не жалею ни капли.