предположим в структуре БД надо немножно что нить поменять, например длину строки-поля на еденичку ))) что надо было сделать раньше? 0. изменить структуру БД 1. может чтото поменять в коде (например длину переменной), а может и нет. что я делаю как .NET программист 0. изменить структуру БД 1. специальной утилитой сгенерировать DAL уровень 2. сбилдить DAL проект 3. изменить XSD схему данных, которую будет получать пользовательское приложение 4. сгенерировать по ней класс 5. сбилдить Contract проект 6. внести изменения в WCF сервис, который непосредственно выбирает данные 7. сбиддить его 8. сделать стоп хосту (в это время все остальные программеры и тестеры малось прифигеют) 9. выложить сборки проектов куда сдедует 10. проверить что все корректно, запустив специальное хостовое приложение 11. стартануть хост 12. сделать чек-ин в TFS 13...n коллеги чтото меняют в клиентах, я в это не лезу вроде все, хотя скорее всего чтото забыл я так чуствую у меня всегда будет хорошооплачиваемая работа ))))
а есть по другому: 1. изменить модель данных 1а. она сама апдейтит базу данных 1б. она сама генерит интерфейс по новой модели данных
в нете работаю с БД через SqlConnection SqlCommand при необходимости SqlDataReader SqlTransaction если то мне нужно всего лишь Если код кривой то и что такое DAL XSD - слышал только в теории.
это щ фигня (мои пункты) мну тут намедни показалось вполне разумным что по сгенеренному DAL'офскому с# коду мона пробежаться самописным парсером и извлечь из него все описания передаваемых юзверю данных, затем на их основе сгенерить схемы данных, а уже на их основе - классы WCF сервисов и сервисов-прокладок между ними. заодно получится унификация в именовании всего этого безобразия. сказано - сделано. и наступил пипец. ят думал что изменение имени контракта на стороне клиента - плевое дело, а фиг мну - оказалось что надо полностью (!!!) переделывать соответствующие инфопасовские формы.... не, мы никогда не останемся без работы, .NET это вещь
1777, такой проект изначально, выбирать нет возможности, вынужден реализовывать аналогичную архитектуру....
яж вроде честно пишу - хорошо от бизталка пока удается отбрыкиваться... от то прикольная штука так прикольная... но тупая шо пипец, отсуда и берутся лишние сервисы - суть они эмуляция бизталковых оркестровок...
Впервые вижу, чтоб в ТЗ еще было написано как нужно делать, а не только что есть, и что надо получить. Или изначально был?
БульЁн, вас берут в "новый" проект, которому два года и десяток человек над ним работает. вы говорите - все это куйня, я буду делать посвоему?
Обычно такое бывает когда делаешь свой велосипед. Я не пользуюсь Net-ом, но думаю что микрософтовщиков должен быть какой-то стандартный подход к этой проблеме и он наверняка проще.
я не в курсе что повлияло на начальном этапе проекта на выбор именно такой его реализации, но то что мы с мелкософтовцами "друзья на век" и они частые гости у нас в конторе подтверждает от такая штука: (вложение) значит так надо.... было....
Что-то невероятно усложнено к тому же DAL, был и до .NET, и объектные модели также А совковое программирование можно и на .NET применять Хочется упрощения используйте скажем LinqToXml или аналогичную технологию количество шагов значительно сократится