Хотелось бы посоветоваться с народом вот по какому вопросу
Приложение разбито на tiers - GUI, BLL, DAL - по-русски говоря - юзер интерфейс, бизнес уровень, дата аксес лэер.

На GUI формочки байндятся к typed Datasets - которые определены на бизнес уровне. DAL реализует заполнения и обновления датасетов, причем DAL как я понимаю должен работать с нетипизировыанными датасетами, дабы быть независимым от BLL

Например есть у меня typed dataset - dsProductList
Я создаю его экземпляр на форме, дальше передаю ссылку на него в BLL метод ProductManagerList.Fill(ByRef ds as dsProductList)

ProductManagerList в свою очередь вызывает метод из DAL - который работает уже с нетипизированным датасетами

ProductDAL.Fill(ByRef ds as DataSet)

который в свою очередь использует хранимую процедуру вызывающую например вот это:

SELECT * FROM Product

Все это нормально работает, однако если я позже добавлю новые колонки в мою БД таблицу Product - я увижу их в гриде моей формы. Невзирая на то, что их нет в описании схемы моего typed dataset на бизнес уровне.

Я так понимаю это проиходит потому, что в DAL я передю свой typed Dataset по ссылке как не typed. И DAL метод радостно заполняет его всем что приходит из БД, схема в данном случае игнорируется.

Возникает вопрос, я что-то делаю совершенно неправильно? Или так оно и должно быть а работу с датасетами надобно организовывать как-то по другому?

Я использую Microsoft Application Data Blocks, метод FillDataset если я ничего не путаю. Настроек адаптера в этом методе нет. Или все же есть?

Alexey Kudinov SM... который в свою очередь использует хранимую процедуру вызывающую например вот это:

SELECT * FROM Product

Все это нормально работает, однако если я позже добавлю новые колонки в мою БД таблицу Product ... Не писать SELECT * FROM Product , а отбирать только те колонки, которые нужны - это в первую очередь.

И как это я сам не догадался :) На самом деле пример упрощен, хранимка используется для несколькиз целей, в разных случая необходимы разные колонки и как я понимаю следующий совет будет - а не написать ли разные хранимки для всяких разных случаев? :)


ЗЫ - и чарджить клиента за каждую отдельную хранимку :)

Alexey Kudinov[quot]Это отнюдь не плохая практика на самом деле. Разные процедуры для "для всяких разных случаев".
Но даже если у вас одна ХП возвращает разные наборы данных для разных случаев, них вы ведь возвращаете только те колонки, которые вам нужны ? Так в чем проблема, если в таблице появится новая колонка ? Если она не нужна - не возвращайте ее.

Или у вас есть одна универсальная выборка "на все случаи жизни", а на клиенте вы из нее "нарезаете" то, что вам нужно ?

На самом деле я с Вами совершенно согласен, я никогда не буду вытаскивать большие объемы ненужных данных, с другой стороны в моем предыдущем проекте было 10 девелоперов и каждому были нужны хранимки причем часто очень похожие по функциональности, но отличающиеся именно наборами колонок. В результате к концу проекта мы имели порядка 2000 хранимок. Теперь представьте какой это был фан все это мэинтейнить :)

В моем конкретном случае к примеру в одном месте мне нужен список продуктов с CategoryID, в другом - без всяких категорий. Выкачка лищних 4 байтов на 500 продуктов в win app и со 100 мегабитной сеткой мне погоды не составит, зато я экономлю на методе DAL, ObjectManager и фасада.

Стр2 SM

в этом случае - увы. у MS в data block это не предусмотрено. если только доопределить самому

какой все таки гадкий этот микрософт :)

V. MotchulskyКак вариант - в гриде прописать стиль.

А грид у меня очень умный, ComponentOne -ский. Судя по всему он автоматически добавляет появившиеся в источнике данных новые колонки
в свою коллекцию колонок.