Вот поддерживаю систему на 1С, и что в ней нравится, это довольно высокая способность к реструктуризации данных. Как правило, формы даже и не замечают что данные поменялись, ну или нужно внести минимальные
изменения в дизайнере и в код... Вот, а с .Net как я понял совсем другая песня... Ради интереса поменял имя
таблицы, а так же имена полей в ней, пришлось долго по коду лазить всё перенастраивать, т.к. даже в дизайнере
форма не открывается уже... Форму восстановил (простенький тестовый примерчик).
А когда реальные проекты пойдут, боюсь не справиться — будет же по нескольку таблиц, связи между ними Есть ли какая-то устоявшаяся методология внесения изменений с минимальными затратами времени на перенастройку датасетов, форм и т.д., что можно почитать по этому поводу? Спасибо.
Re: Устойчивость системы к изменению структуры данных
Здравствуйте, Аким, Вы писали:
А>Вот поддерживаю систему на 1С, и что в ней нравится, это довольно высокая способность к реструктуризации данных. Как правило, формы даже и не замечают что данные поменялись, ну или нужно внести минимальные А>изменения в дизайнере и в код... Вот, а с .Net как я понял совсем другая песня... Ради интереса поменял имя А>таблицы, а так же имена полей в ней, пришлось долго по коду лазить всё перенастраивать, т.к. даже в дизайнере А>форма не открывается уже... Форму восстановил (простенький тестовый примерчик). А>А когда реальные проекты пойдут, боюсь не справиться — будет же по нескольку таблиц, связи между ними Есть ли какая-то устоявшаяся методология внесения изменений с минимальными затратами времени на перенастройку датасетов, форм и т.д., что можно почитать по этому поводу? Спасибо.
Устойчивость к изменениям в структуре данных, которая реализована в системе 1С, а также гибкость системы в целом, достигнута за счёт применения тех же вполне конкретных вещей, но на мета-уровне. Т.е. есть уровень абстракции данных, который обрабатывается специальной логикой. Dataset в программе — это вполне конкретная вещь "низкого" уровня (вот до чего дожились... раньше ассемблер был ), а в 1С конйигураторе нет возможности работать с данными напрямую.
Мне кажется вопрос некорректный. .NET — это система проектирования приложений — среда программирования (native), а 1С конфигуратор — это всё та же система настройки прикладного программного продукта — не более того (pseudo).
-------------------------------
Всё пройдёт, пройдёт и это...
Всё пройдёт... Пройдёт и это.
Re[2]: Устойчивость системы к изменению структуры данных
DA>Мне кажется вопрос некорректный. .NET — это система проектирования приложений — среда программирования (native), а 1С конфигуратор — это всё та же система настройки прикладного программного продукта — не более того (pseudo).
Спасибо, мне кажется вопрос вполне корректный. Задача не в реализации под Net архитектуры 1С а
в освоении правильной методологии внесения изменения в существующую структуру таблиц. Я не стремлюсь
к максимальной универсализации (ибо плата за это высока весьма) а именно хочу чётких инструкций:
Нужно добавить/изменить/удалить — таблицы/поля/связи — которые уже используются в приложении. Чёткий
план действий — "пойди туда, подкрути то, обрати внимание на следующее". Методом проб и ошибок я конечно
же разберусь (уже начал), но боюсь и времени это отнимет массу, и навыки скорее всего получу "кустарные"
Спасибо за любую инфу, ссылки, книги по данной проблематике.
Re[3]: Устойчивость системы к изменению структуры данных
Здравствуйте, Аким, Вы писали:
А>Здравствуйте, DrAg0n, Вы писали:
DA>>Мне кажется вопрос некорректный. .NET — это система проектирования приложений — среда программирования (native), а 1С конфигуратор — это всё та же система настройки прикладного программного продукта — не более того (pseudo).
А>...Я не стремлюсь А>к максимальной универсализации (ибо плата за это высока весьма) а именно хочу чётких инструкций: А>Нужно добавить/изменить/удалить — таблицы/поля/связи — которые уже используются в приложении.
...Вот это и есть по 1С-овски. А когда программируешь на native-языке, ты несёшь полную ответственность за соответствие структуры данных БД и логики программы её использующей.
А>Спасибо за любую инфу, ссылки, книги по данной проблематике.
Лично я выбрал для изучения C#.NET книжку ISBN 5-93286-038-3 Здесь есть и описание самого языка с объектной-ориентацией по шарповски, и примеры применения для разработки.
Всё пройдёт... Пройдёт и это.
Re: Устойчивость системы к изменению структуры данных
Здравствуйте, Аким, Вы писали:
А>Вот поддерживаю систему на 1С, и что в ней нравится, это довольно высокая способность к реструктуризации данных. Как правило, формы даже и не замечают что данные поменялись, ну или нужно внести минимальные А>изменения в дизайнере и в код... Вот, а с .Net как я понял совсем другая песня... Ради интереса поменял имя А>таблицы, ...
Ну-Ну... Ты это о чем?
Ты открой Enterprise Manager, и поменяй имя таблицы (например SC33 на SC_33 ), и посмотри как у тебя 1С раскорячится!
Ну например так.
Есть у него карточка товара. Он создает класс GoodsCard. Этот класс отвечает за выборку данных и их изменение. Вторым этапом создается GoodCardForm — форма для отображения информации о карточке товара. Коструктор в качестве параметра получает объект aGoodsCard.
Перед отображением происходит инициализация формы:
this.editBox1.Text = aGoodsCard.GetGoodsName();
this.editBox2.Text = aGoodsCard.GetGoodsId();
GoodsParametr [] params = aGoodsCard.GetGoodsParametrs();
foreach(GoodsParametr oneParam in params)
{
...
//GoodsParametr - тоже самописный класс для отображения параметров
}
GoodsPrice [] price = aGoodsCard.GetGoodsPrices();
....
//Ну и так далее
//Теперь изменить параметр
aGoodsCard.SetAddParam(GoodsParametr aGoodsParametr);
//Ну и теперь сохранить все изменения в БД
aGoodsCard.CommitWork();
Таким образом форме без разницы откуда прошла инициализация карточки. Например тим лидер захотелось что бы цены товара хранились не в одной таблице строками, а каждая цена в своей таблице (хптел бы я на такого взглянуть ). Нужно изменить только способ выборки информации, а форма даже и не заметит ничего. Более того — если эту инфу формировать процедурой на серваке — вынести логику туда — так и компилируемый код менять не надо.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Устойчивость системы к изменению структуры данных
Здравствуйте, bralgin, Вы писали:
B>Ну-Ну... Ты это о чем? B>Ты открой Enterprise Manager, и поменяй имя таблицы (например SC33 на SC_33 ), и посмотри как у тебя 1С раскорячится!
И _как_ она раскорячится? Да, справочник, лежащий в sc33, будет пустым... Потеряются ссылки. Но это не раскорячка.
... << RSDN@Home 1.1.4 stable rev. 510>>
Re[4]: Устойчивость системы к изменению структуры данных
Здравствуйте, SEDEGOFF, Вы писали:
SED>Ну например так. SED>Есть у него карточка товара. Он создает класс GoodsCard. Этот класс отвечает за выборку данных и их изменение. Вторым этапом создается GoodCardForm — форма для отображения информации о карточке товара. Коструктор в качестве параметра получает объект aGoodsCard. SED>Перед отображением происходит инициализация формы: SED>
SED>this.editBox1.Text = aGoodsCard.GetGoodsName();
SED>this.editBox2.Text = aGoodsCard.GetGoodsId();
SED>GoodsParametr [] params = aGoodsCard.GetGoodsParametrs();
SED>foreach(GoodsParametr oneParam in params)
SED>{
SED>...
SED>//GoodsParametr - тоже самописный класс для отображения параметров
SED>}
SED>GoodsPrice [] price = aGoodsCard.GetGoodsPrices();
SED>....
SED>//Ну и так далее
SED>//Теперь изменить параметр
SED>aGoodsCard.SetAddParam(GoodsParametr aGoodsParametr);
SED>//Ну и теперь сохранить все изменения в БД
SED>aGoodsCard.CommitWork();
SED>
SED>Таким образом форме без разницы откуда прошла инициализация карточки. Например тим лидер захотелось что бы цены товара хранились не в одной таблице строками, а каждая цена в своей таблице (хптел бы я на такого взглянуть ). Нужно изменить только способ выборки информации, а форма даже и не заметит ничего. Более того — если эту инфу формировать процедурой на серваке — вынести логику туда — так и компилируемый код менять не надо.
Интересно, как часто возникает надобность в таком изменении структуры данных, что ненужно менять ничего кроме способа выборки? И во что выльется создание ещё одного абстрактного слоя?
Вот весело то будет писать функции типа GetGoodsName(), GetGoodsId(), GetGoodsParametrs() и т.д. А потом ещё аналогичный набор сеттеров, а потом ещё подумать о синхронизации с БД, а потом ещё вспомнить о биндинге контролов ко всему этому делу, о том что данные должны забираться только 1 раз и храниться только в одном месте (ну чтоб строка скажем с названием производителя хранилась в памяти приложения в единственном экземпляре). Тут, наверное, могут конкретно помочь средства объектно-реляционной проекции (ORM) — по ссылке статья Сергея Тарасова "Обзор средств объектно-реляционной проекции (ORM) для платформы .NET".
Кстати, если у тимлиду захотелось поменять структуру БД на SQL-сервере, Вам не обязательно менять структуру данных приложения — в смысле DataSet.
Главное гармония ...
Re[5]: Устойчивость системы к изменению структуры данных
Ссылка не верная — опубликуй пожалуйста еще раз.
А надобность возникает по мере получения опыта. Программист развивается всегда. Поэтому проектируя — нужно "видеть" будующее. В любом случае я не навязываю своем мнение, а делюсь опытом.
Могу привести пример из жизни. Переписываем большой блок кода из двухзвенки в трех — повышается производительность. И если бы изначально было реализовано как в моем примере — форму бы переделывать не пришлось (де и не только форму). Вместо этого мы просто все переписываем.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Устойчивость системы к изменению структуры данных
Здравствуйте, SEDEGOFF, Вы писали:
SED>Ссылка не верная — опубликуй пожалуйста еще раз. SED>А надобность возникает по мере получения опыта. Программист развивается всегда. Поэтому проектируя — нужно "видеть" будующее. В любом случае я не навязываю своем мнение, а делюсь опытом.
Я просто отметил, что только введение дополнительной абстракции к слою данных не спасёт от действительно значительных изменений в структуре БД (которые думаю не так часто происходят. а если и происходят, то наверняка влекут и серьёзные изменения в интерфейсе. ИМХО). А скажем переименование таблицы в БД не обязывает переименовывать её в ДатаСете. Ну или в вашем примере с карточками товара — просто перепешите соответствующий DbAdapter.SelectCommand и всё.
SED>Могу привести пример из жизни. Переписываем большой блок кода из двухзвенки в трех — повышается производительность. И если бы изначально было реализовано как в моем примере — форму бы переделывать не пришлось (де и не только форму). Вместо этого мы просто все переписываем.
Если не секрет, а на чём написано/переписывается приложение?
Главное гармония ...
Re[2]: Устойчивость системы к изменению структуры данных
Здравствуйте, SEDEGOFF, Вы писали:
SED>C++ Bulder 6
Интересно. Думаю что сейчас это выглядит примерно так:
1) Данные (что-нибудь от Accsess до SQL-сервера)
2) Компоненты доступа к данным (что-нибудь от BDE до dbExpress)
3) Формы с TDBEdit'ами (кажется их назывыают db-Aware Control, поправьте пожалуйста)
Если всё так, то почему бы не попробовать воспользоавться MIDAS'ом. Заменить TTable'ы на TClientDataSet'ы и не трогать контролы, на сервере приложений разместить провайдеры данных, попривязывать их к любым ДатаСетам и подсовывать клиентам ожидаемые ими данные.
PS
Сейчас участвую в подобном проекте, пытаюсь реализовать именно такую схему. Раньше с 3-х звенками дело не имел, так что чувствую как ежик в тумане на поле усеяном граблями.
Главное гармония ...
Re: Устойчивость системы к изменению структуры данных
M>1) Данные (что-нибудь от Accsess до SQL-сервера)
FireBird M>2) Компоненты доступа к данным (что-нибудь от BDE до dbExpress)
IBX M>3) Формы с TDBEdit'ами (кажется их назывыают db-Aware Control, поправьте пожалуйста)
Просто TEdit, про db-Aware Control — не разу не слышал, поэтому сказать ничего не могу
Используется TIBClientDataSet + TIBSQL для коротких запросов и инициализации разных контролов.
С MIDAS никак не общался — ничего сказать не могу. Третье звено выделилось "само" — теперь доводим до ума (как сразу не увидели , не пойму ). В подробности вдаваться не буду, но прирост в производительности по сравнению с текущей системой составил где то в 10 — 15 раз. Это на протатипе. Ну MIDAS посмотрим — мож по более выручка будет M>Если всё так, то почему бы не попробовать воспользоавться MIDAS'ом. Заменить TTable'ы на TClientDataSet'ы и не трогать контролы, на сервере приложений разместить провайдеры данных, попривязывать их к любым ДатаСетам и подсовывать клиентам ожидаемые ими данные.
M>PS M>Сейчас участвую в подобном проекте, пытаюсь реализовать именно такую схему. Раньше с 3-х звенками дело не имел, так что чувствую как ежик в тумане на поле усеяном граблями.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Устойчивость системы к изменению структуры данных
Здравствуйте, SEDEGOFF, Вы писали:
M>>3) Формы с TDBEdit'ами (кажется их назывыают db-Aware Control, поправьте пожалуйста) SED>Просто TEdit, про db-Aware Control — не разу не слышал, поэтому сказать ничего не могу
Просто TEdit? Может TDBEdit? Если всё-таки TEdit, то неужели руками реализовывали передачу из Edit1->Text в DataSet ?
А db-Aware controls это и есть все эти TDBEdit, TDBComboBox, TDBListBox ... .
SED>Используется TIBClientDataSet + TIBSQL для коротких запросов и инициализации разных контролов. SED>С MIDAS никак не общался — ничего сказать не могу. Третье звено выделилось "само" — теперь доводим до ума (как сразу не увидели , не пойму ). В подробности вдаваться не буду, но прирост в производительности по сравнению с текущей системой составил где то в 10 — 15 раз. Это на протатипе. Ну MIDAS посмотрим — мож по более выручка будет
Интересно, а как в прототипе клиенты от сервера приложений отделены, как взаимодействуют ?
Есть ли какая-то устоявшаяся методология внесения изменений с минимальными затратами времени на перенастройку датасетов, форм и т.д., что можно почитать по этому поводу? Спасибо.
раньше ассемблер был 
), а в 1С конйигураторе нет возможности работать с данными напрямую. 
). Нужно изменить только способ выборки информации, а форма даже и не заметит ничего. Более того — если эту инфу формировать процедурой на серваке — вынести логику туда — так и компилируемый код менять не надо.
