nicktcher1, 2 - это детсадовские истины, и я не вижу здесь никакого противоречия с подходом, примененным в платформе 1С.
3. Такая возможность у Вас есть всегда, в т.ч. и при работе с 1С. Вопрос в целесообразности. И движок это действительно делает, а не "якобы делает". Если бы он это не делал, система была бы неработоспособна.
4. 1С как никакая другая платформа облегчает подобные затраты. А проблемы производительности 1С на 99% связаны со стремлением разработчиков 1С обеспечить всеядность платформы в плане поддержки различных БД. Это момент спорный. Я бы лично тоже предпочел, чтобы платформа поддерживала 1, ну max 2 БД. Но тут, видимо, победил чисто маркетинговый подход и стремление объять необъятное.
5. Давайте придерживаться общепринятой терминологии. Есть нисходящее проектирование, есть восходящее проектирование (если Вы это имели в виду). Во всем нужно придерживаться здорового прагматизма и не зацикливаться на одном подходе. Оба подхода имеют право на жизнь вне зависимости от масштабов проектируемой системы. Платформа (1С или другая), безусловно, накладывает свой отпечаток на применении тех или иных подходов, но не стоит придавать этому слишком драматическое значение.
1,2 - естественно. Насколько я помню это было применено для последовательности изложения
3. Когда появилась такая возможность? Т.е., к примеру, я могу стандартный метод создания объекта в 1С заменить, ну допустим, на хранимую процедуру в БД. Если не тяжело, подскажите куда посмотреть.
4. Облегчает не более и не менее чем другие, среднебольничные.
5. Я же не говорю, что такой подход не имеет права на жизнь. Речь шла о том, что не имеется возможности вмешаться в то, что система "нагенерит" на более низких уровнях. Хотя, я может что-то пропустил (см. пункт 3) и сейчас уже такая возможность есть. Все же теме 3 года :)

nicktcher3. Я говорю не о хранимых процедурах, см. п.4. Ради универсальности 1С пришлось, к сожалению, пожертвовать эффективностью. Но ADO никто не отменял. Структура хранения данных 1С - не есть тайна. Работайте с базой напрямую (под вашу ответственность), производительность будет выше в разы. Открою тайну - многие 1Сники так и делают, если нужно обрабатывать большие массивы данных и время обработки критично.
4. Не согласен. Интерфейс в 1С(если не говорить об убогом новомодном декларативном в 8.2) строится на порядок быстрее, красивее и эффективнее, чем у некоторых конкурентов. Сравните с Аксом хотя бы). Это сильная сторона 1С имхо.
5. Давайте отделять мух от котлет. Мы же говорим о платформе, а не о голом низкоуровневом программировании. Именно платформа берет на себя низкоуровневое взаимодействие, оставляя прикладному разработчику время на то, чтобы заняться проблемами автоматизации предметной области, и это единственно правильный подход для промышленной платформенной разработки, если мы говорим не об учебных книжных экспериментах на уровне 2-х табличек employees и departments. Иначе непонятно становится зачем нужна вообще платформа. Можно всё рисовать руками - и таблицы и индексы и триггеры и хранимые процедуры. Да, это тоже бывает полезно, но сделаете ли Вы серьезную систему при этом? Уверен, что нет
3. И я тоже не конкретно о хранимых процедурах. Там же написано, "допустим". Вчитайтесь внимательней в смысл темы, пожалуйста. В ней идет речь о невозможности вмешаться, при необходимости, в интерфейсы более низкого уровня. Т.е. обучить генератор более верхнего уровня работать с данными подобающим образом. Наросты "сбоку" не рассматриваются.
4. Сравните с Делфи, например, и иже с ними. Я и говорю, среднебольнично. Кстати "управляемое приложение" и декларативный интерфейс - огромный шаг вперед, в том числе и в сторону скорости разработки. Просто для работы по таким принципам нужно немного мышление повернуть. Ничего, привыкнете.
5. Вы правы, можно рисовать базу данных и руками. "но сделаете ли Вы серьезную систему при этом? Уверен, что нет". А я почему-то уверен, что да. Я же не придумываю это на ходу, системы делаю и заметьте не на 1С

nicktcher,

так что, под возможностью определять методы работы с СУБД Вы имели ввиду наросты "сбоку" в виде ADO?

_модiscrafmгде имеет возможность? Или это идет речь о "как должно быть"?
Есть (и д.б.) во многих подобных системах.
понятно. Речь в топике шла о конкретной.

nicktcherПрекрасно. Успехов Вам, искра. Примеры ваших сделанных в подобном стиле систем в студию, если можно. И функционал опишите вкратце, плиз. Заодно укажите приблизительные сроки изготовления оных систем и технологию их сопровождения
Можете просто профиль посмотреть и на сайте описания, на сайтах партнеров. Там и про приблизительные сроки и про технологию сопровождения. Кстати сроки почему-то получались в 3-4-5 раз меньшие, чем предлагали заказчикам 1С. Парадокс?

nicktcher"управляемое приложение" и декларативный интерфейс - огромный шаг вперед, в том числе и в сторону скорости разработки. Просто для работы по таким принципам нужно немного мышление повернуть. Ничего, привыкнете.


Нет, это не шаг вперед. Это вообще не шаг. Это прикручивание сомнительных рюшек там, где и так всё работало на ура. А реальные проблемы не решены. А управляемые формы - верх убожества. Это мнение подавляющего большинства спецов. Можно привыкнуть и к убожеству, не спорю. Но оно от этого не перестанет быть таковым.
[/quot]
Значит просто не ваше. Искра изначально так была построена в 2005 году, 1С - с версии 8.2. Переход на управляемое приложение по всем параметрам значительный плюс. Но... агитировать же не буду. Рисуйте формочки руками и прописывайте все в коде.

nicktcheriscrafm,

Вы представитель искры фм? И позиционируете её типа как платформу? Вы хотите сказать, что Вы там руками всё настраиваете?
Тогда вопрос - зачем вообще нужна ваша искра? Если Вы и ручками всё делаете - флаг в руки, зачем платформа-то нужна?
я не знаю что такое "искры фм" к сожалению. Ручками не все конечно делается. Иначе как один человек мог бы, как я уже говорил чуть выше, в 3-4-5 раз быстрее что-то делать, чем на 1С? Вы тему то прочитайте все же, о чем речь идет...

Не ИСкраГде-то, возможно, и плюс, но во многих случаях - минус.Минус по одной простой причине, в ней, как и 1С,ORM заложены определенные принципы и ограниченные возможности, которые нельзя изменить.
например?
методы работы с базой можно изменить, отображение любое можно и т.п. Никто просто этого не делает, потому что нет необходимости. На моей памяти только 1 раз мы отдавали SDK, чтобы компания-пользователь все поменяла на свое усмотрение.

nicktcherФормы в классическом виде прекрасно и безпроблемно рисуются.
В коде реализуется бизнес-логика. Возможность динамического управления интерфейсом из кода - это плюс, который, кстати, ни к чему не обязывает.
А управляемую форму невозможно ни настроить, ни подстроить, она будет такой "как фишка ляжет", нравится это пользователю или нет. Вот в этом и заключается убожество имхо.
думаю это просто вопрос времени. Будет спрос на какие-то изысканные варианты отображения, добавят возможность их описания. То что есть сейчас вполне достаточно для 99.99% процентов форм. Я не говорю в целом об интерфейсе (типа рабочий стол, риббоны и т.п.). Лично мне он слишком отвлекает от работы с данными и занимает много места. Но то, что дошли до компоновки, а не бросания контролов +. А остальное со временем устаканится. Главное курс правильный взять. Имхо конечно.