Уважаемые all, хотелось бы узнать ваше мнение насчет того, как лучше проектировать систему автоматизации предприятия:
1) Сделать как в 1С или Аксапте, т.е. есть внутрений язык и структура метаданных на основе которых строятся различные объекты (формы, справочники, отчеты).
2) Зашить все (например, формы и отчеты) жестко.

В данный момент мы пишем по первому подходу, для конкретного предприятия, но есть желание сделать более менее универсальную систему, которую можно было бы, использовать дальше, при этом не переписывая под новое предприятие. При этом есть в фирме есть опыт написания системы по второму подходу, и те кто это делал говорили, что второй подход даже медленее первого.

В связи с этим и возник вопрос, что лучше первое или второе? А может есть еще другие подходы?

Здравствуйте, Васильев Артём, Вы писали:

ВА>1) Сделать как в 1С или Аксапте, т.е. есть внутрений язык и структура метаданных на основе которых строятся различные объекты (формы, справочники, отчеты).

Имеет смысл в том случае, если ты хочешь позволить другим дорабатывать и развивать свою архитектуру.

Например, если ты делаешь тиражируемое решение.

Здравствуйте, Васильев Артём, Вы писали:

ВА>Уважаемые all, хотелось бы узнать ваше мнение насчет того, как лучше проектировать систему автоматизации предприятия:
ВА>1) Сделать как в 1С или Аксапте, т.е. есть внутрений язык и структура метаданных на основе которых строятся различные объекты (формы, справочники, отчеты).
ВА>2) Зашить все (например, формы и отчеты) жестко.

Однозначно, первый вариант.

Здравствуйте, Васильев Артём, Вы писали:

ВА>1) Сделать как в 1С или Аксапте, т.е. есть внутрений язык и структура метаданных на основе которых строятся различные объекты (формы, справочники, отчеты).
ВА>2) Зашить все (например, формы и отчеты) жестко.

[...]

ВА>В связи с этим и возник вопрос, что лучше первое или второе? А может есть еще другие подходы?

Вот история проекта который развивался по первому подходу
http://www.livejournal.com/~anatolix/577.html

Рекомендую учиться на моих ошибках , а не на своих.

Здравствуйте, Васильев Артём, Вы писали:

ВА>1) Сделать как в 1С или Аксапте, т.е. есть внутрений язык и структура метаданных на основе которых строятся различные объекты (формы, справочники, отчеты).
ВА>2) Зашить все (например, формы и отчеты) жестко.

Мне кажется оптимальным будет попытаться сочетать оба подхода. Т.е. система должна позволять описывать себя в рантайме с помощью метаданных, скриптов и т.п., но в то же время должна быть возможность включения в систему бинарных модулей (при условии что они отвечают определенным требованиям, например реализуют какие-то стандартные интерфейсы и т.п.).

Здравствуйте, Anatolix, Вы писали:

A>Вот история проекта который развивался по первому подходу
A>http://www.livejournal.com/~anatolix/577.html

Везде-ж её всунет..
Вот только никаких внятных выводов в сиём произведении я не увидел.

Здравствуйте, Dimonka, Вы писали:

D>Здравствуйте, Anatolix, Вы писали:

A>>Вот история проекта который развивался по первому подходу
A>>http://www.livejournal.com/~anatolix/577.html

D>Везде-ж её всунет..
D>Вот только никаких внятных выводов в сиём произведении я не увидел.

Не нравится не читай — если уже читал. Выводы там есть — просто возможно либо ты не готов их воспринять, либо они для тебя очевидны.

Просто здесь из 4 ответов 3 человека посоветовали ввязаться в авантюру написания своего средства разработки, предварительно не предупредив, что для этого нужны серьезные инвестиции, для того чтобы получилось средство которое уcкоряет разработку, а не замедляет. Поэтому я просто осветил свою альтернативную точку зрения.

Притом обрати внимание я нигде не сказал человеку "не нужно этого делать". Я просто предоставил ему информацию. Он осмыслит ее со своей точки зрения. Если его аргументация для чего нужна такая система будет похожа на ту, что была у нас сделает свои выводы, если не похожа, то тоже сделает.

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

1) Потому что языки и дизайнеры форм это круто — всегда мечтал написать свой язык
не стоит писать.
2) Потому что у всех конкурентов есть настройки
тоже не стоит писать. Во первых они вам не конкуренты — они в более высокой ценовой нише. Во вторых объяснение "т.к. у всех есть" это вариант проявления Культа карго.
3)Потому что тогда нашу систему смогут настраивать другие люди — заказчии и партнеры
ага щаззз. В очередь выстроились. Заказчики ничего точно писать не будут, а партнеры появятся когда их доходность от вашей системы будет больше чем от 1С или R3. Т.е. когда все уже будет готово, стоить будет дорого, а настраивать нужно будет по минимумуму.
4) Потому что мы хотим перейти в другой класс систем, мы понимаем, что после этого нашими кокурентами будут системы типа 1С,R3 ми другие. Понимаем что это потребует инвестиций сравнимых с ними. Но это нам нужно для того чтобы развивать партнерскую сеть, и у нас уже есть партнеры, мы не думаем наивно, что как только мы напишем макроязык к нам в очередь выстроятся люди готовые на нем писать.
Вот только в этом случае я бы сказал что стоит подумать. Предварительно поняв, самый ли это хороший метод — написание своего средства разработки и не стоит ли рассмотреть следующие альтернативы:
1) (частично) открыть исходники продукта — путь их можно будет дописывать.
2) Предоставить API в виде plugin-ов, или интерфейсов COM/Corba. Тогда партнеры смогут писать программы не на VasyapupkinScript, а на языках программирования которые они знают и пользоваться IDE которые им удобны.
3) Купить, то что они хотят написать. Т.е. например VBA поюзать.
4) Просто взять готовую систему, например настраивать IFS, Axapta или R3.