1C vs. nexus

Когда я открыл конфигуратор 1С предприятие 8.1, то был поражен тем, что увидел классы а-ля нексус. Правда их было гораздо больше, они могли содержать в себе элеменыы иерархические. Но наследования классов, как в нексусе, я не обнаружил. Видимо это будет в будущем.

Если подсчитать время выхода нексуса и 1С, то можно сказать, нексус родился лет на 20 раньше положенного.

Безусловно приятно работать в 1С. Правда встроенный язык русский. Для меня это не привычно. Как быть?

Комментарии

1С 7.7 прекрасно

1С 7.7 прекрасно понимает конструкции языка на англиуском. думаю в 8 cерии тоже самое.
единственная проблема - наименования объектов системы. тут уж никуда не денешься.

Приятная 1С :)

Что может быть приятного в 1С?.. Меня всегда искренне изумляло такое... "проектирование"... Мне представляется, что разработчики просто не понимали предметную область.

Изображение пользователя ipanshin.

Отправной

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

А в плане проектирования в кавычках я как-то не заморачиваюсь. Привык, видимо, уже, как робинзон Крузо строить из подручных средств какие есть вокруг. А что существуют какие-то методики проектирования с доказательством их правильности? Мне кажется, что этот вопрос В.А.Каймина. И потом "проектирование" не должно в принципе принадлежать какой-либо предметной области.

Предметная область

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

Проектирование должно исходить из понимания предметной области... Если нет понимания, то... что собственно проектируют?

Изображение пользователя st.

Понимание

Если бы роль понимания ПрОбласти было столь существенна, невозможно было бы создать универсальные устройства, программы, механизмы и пр.

Наоборот

С точностью до наоборот. Именно из понимания предметных областей и произрастает нормальный "универсализм".
Например, из понимания сути бух. учета можно без труда создать универсальную бухгалтерскую подсистему, которая легко настраивается на российскую бухгалтерию, МФО, GAAP и пр.

Изображение пользователя st.

Фон Нейман

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

Ложкомолоток

Фон Нейман - умница, он придумал "идеального" исполнителя. И Нейману совершенно не надо было знать, где будет применяться этот исполнитель. Его предметная область была совершенно иная... Тот, кто придумал гвоздь понятия не имел ни о моем соседе, ни о его бетонной стенке, в которую этот сосед второй день гвоздь вколачивает... :)
Преследователи "вселенских масштабов" - это как раз те, кто не понимают, что и для чего они создают. (Из серии попыток создать "универсальный" ложкомолоток)
При реализации той же бухгалтерии могут использоваться решения, которые с успехом применяются для решения совершенно иных задач. Понимаете?.. Не надо каждый раз изобретать "гвоздь", в том и польза от универсальности.
Если кто-то сделал удачный классификатор, который может с успехом применяться в разных предметных областях, то это означает, что создатель классификатора хорошо понял суть классификаций - этому и посвящено его решение, это и есть его предметная область.

Изображение пользователя st.

Создатели

Создатели универсального программного обеспечения также не имеют полного представления, где конечному пользователю придет в голову использовать их продукт.

Про топор

Совершенно верно, поэтому... если они... толковые специалисты, то они оформляют свое универсальное ПО, как инструмент (забивать гвоздь можно и обухом топора, но держаться удобнее за рукоятку).

Изображение пользователя st.

Хорошо

Хорошо, значит хотя бы инструменты можно проектировать без глубокого знания ПрОбл.

Топорная... архитектура

Нет, нельзя. Создание инструмента - это отдельная предметная область, отличная от тех предметных областей, где этот инструмент используется. Тот, кто создает топор, может быть профаном в архитектуре и строительстве.

Изображение пользователя st.

Таким образом

Таким образом создатель моделирующего архитектурного пакета типа ArchiCAD может быть "профаном в архитектуре и строительстве"

Изображение пользователя ipanshin.

Я хочу только

Я хочу только акцентировать внимание аудитории на следующий факт. Допустим, мы написали простейшую формулу:

P1V1 = P2V2

Ктото скажет, что это закон сохранения импулься, а кто-то признает закон термодинамики. Можно, видимо найти еще ряд предметных областей, в которых это уравнение имеет смысл. Но, однако, математически оно строго осталось неизменным. Из этого факта я исхожу, что существует область, которая не принадлежит предметной или является общей для всех предметных областей. А раз есть такая область, то и проектировать в ней тоже можно.

Изображение пользователя ipanshin.

К сожалению это

К сожалению это не так. Инструмент никогда не создавался отдельно. Применительно к платформе 1С существует в одном флаконе и инструмент (конфигуратор) и сама система (как продукт для конечного пользователя). Как, в общем это сделано и в нексусе версии 252. Правда, мой пофигуратор кажется беднее, хотя я особенно этим не заморачиваюсь. (Кроции наследуют землю).

Не берусь судить, но ... Тот, кто создает топор и профан в архитектуре и строительстве, тот создаст топор для убийства и войны только. И другого не дано, к сожалению.

Я же продолжаю исследования 1С Vs.Nexus, если кому интересно, то могу сказать, что на данный момент можно не только откомпилировать в 1С скрипт нексуса, но и наоборот, загрузить базу данных 1С в БД нексуса и все прекрасно работает в двух интерфейсах. Это относится и к 7.7 и к 8.1. То есть таким образом мы можем спокойненько обойти тот API, который нагородили разработчики 1С со своим сервером приложений, естественно не руша никоим образом работу его, и оставаясь на позициях голого сиквела. Правда, разработчик должен понимать структуру полей и таблиц данных. Это, конечно, не просто, но возможно.

Интерес такого подхода состоит в том, чтобы опять венуть ту производительность, которая была потеряна в процессе внедрения API платформы 1С и отхода от SQL кода, как например

exec sp_executesql N'SELECT TOP 30
_Reference121_R._IDRRef AS _A1RRef,
_Reference121_R._Marked AS _A2,
_Reference121_R._Folder AS _A3,
_Reference121_R._ParentIDRRef AS _A4RRef,
_Reference121_R._IsMetadata AS _A5,
_Reference121_R._Description AS _A6,
_Reference121_R._Code AS _A7,
_Reference121_R._Fld2025RRef AS _A8RRef,
_Reference121_R._Fld2034RRef AS _A9RRef,
_Reference121_R._Fld2047RRef AS _A10RRef,
_Reference121_R._Fld2037 AS _A11,
_Reference121_R._Fld2040 AS _A12,
_Reference121_R._Fld2036RRef AS _A13RRef,
_Reference121_R._Fld2043RRef AS _A14RRef,
_Reference121_R._Fld2041RRef AS _A15RRef,
_Reference121_R._Fld2024 AS _A16,
_Reference121_R._Fld2058RRef AS _A17RRef,
_Reference121_R._Fld2049RRef AS _A18RRef,
_Reference121_R._Fld2044RRef AS _A19RRef,
_Reference121_R._Fld2032 AS _A20,
_Reference76._Description AS _A21,
_Reference36._Description AS _A22,
_Reference75._Description AS _A23,
_Reference123._Code AS _A24,
_Reference122._Description AS _A25,
_Reference232._Description AS _A26,
_Reference90._Description AS _A27
FROM
_Reference121 _Reference121_R WITH(NOLOCK)
LEFT OUTER JOIN _Reference90 WITH(NOLOCK)
ON _Reference121_R._Fld2049RRef = _Reference90._IDRRef
LEFT OUTER JOIN _Reference232 WITH(NOLOCK)
ON _Reference121_R._Fld2058RRef = _Reference232._IDRRef
LEFT OUTER JOIN _Reference122 WITH(NOLOCK)
ON _Reference121_R._Fld2041RRef = _Reference122._IDRRef
LEFT OUTER JOIN _Reference123 WITH(NOLOCK)
ON _Reference121_R._Fld2043RRef = _Reference123._IDRRef
LEFT OUTER JOIN _Reference75 WITH(NOLOCK)
ON _Reference121_R._Fld2036RRef = _Reference75._IDRRef
LEFT OUTER JOIN _Reference36 WITH(NOLOCK)
ON _Reference121_R._Fld2034RRef = _Reference36._IDRRef
LEFT OUTER JOIN _Reference76 WITH(NOLOCK)
ON _Reference121_R._Fld2025RRef = _Reference76._IDRRef
WHERE
_Reference121_R._ParentIDRRef = @P1
ORDER BY
_Reference121_R._Folder,
_Reference121_R._Description,
_Reference121_R._IDRRef',N'@P1 varbinary(16)',0x7695001FC60839A011DDDD9BFB03CF88

Я не могу понять смысл использования здесь динамического сиквела. Ведь по правде говоря, он здесь не нужен. Почему бы не вставить вместо параметра саму переменную? Все равно этот сиквельный код генерируется сервером приложений 1С. А использование многократно LEFT OUTER JOIN конструкций вообще ведет в некоторых случаях к деградации производительности. Особенно, если таблица типа номенклатуры. А ведь _Reference121 - это номенклатура, не правда ли? В общем это один из примеров 1C API недоделок. Есть и другие.

Другой интерес данного подхода дает возможность воспользоваться еще одним преимуществом такой СУБД, как MS SQL. Я говорю о системе репликаций и распределенных БД. Понятно, что чтото предоставляют разработчики 1С, когда они говорят о распределенных БД. Но еще больше предоставляет сама СУБД. Хочется иметь возможность воспользоваться большим. Поэтому уход на уровень сиквела зачастую целесообразен...

Весеннее, питерское

Негромко погода дождем застучала.
Подумай, ведь это - рожденья начало,
Когда вдруг набухнут и лопнут все почки,
Тогда отчего ж у тебя ни пол-строчки?

О том, как Весною оттают все люди,
и кто-то поверит, а может полюбит,
И кто-то с надеждой в толпе многоликой
Вдруг вспомнит Отчизну счастливой, великой.

Умыты грозою все мысли и грезы,
Склонились лишь низко родные березы,
Над софьей и верой, надеждой, любовью...
Слова все простые - написаны кровью.

Вот и я написал что-то.
26 мая 2009