И еще раз о Microsoft

Сегодня прочитал пару занимательных заметок на Cnews.ru. http://www.cnews.ru/news/top/index.shtml?2005/12/27/193861 и http://www.cnews.ru/reviews/free/offshore/soft/index2.shtml

Первая заметка показывает отношение Microsoft к своему маркетингу. Маркетинг грамотный, что еще раз показывает каков уровень специалистов-маркетологов. Понятно, и тут те, кто занимался shareware меня поймут, что никаких гарантий того, что деньги вложенные в этот фонд вернутся, вообще нет. По смыслу, я во всяком случае так понял, что главный критерий, по какому будут отбираться претенденты на легкие деньги - применение .NET в своих приложениях. О том, как будут тратится эти деньги вообще вопросов не будет. Цену товару будут рекомендовать специалисты Softkey. Ну о том, как будет продвигаться тот или иной продукт, вообще разговоров нет. Так вот, Microsoft возврат этих, в общем-то небольших, денег и не нужен. Компании нужно набрать критическую массу разработчиков и разработанных ими приложений, а для этого все средства хороши.

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

Вопросы производительности ECO

Существует несколько аспектов, которые влияют на производительность ECO приложения:

1. Сама технология. Overhead относительно приложений, написанных без применения ECO составляет 10-15%. Не очень много.
2. В случае разработки многопользовательских приложений свою лепту вносит .NET Remoting. Который сам по себе не очень быстрый.

Можно сказать, что приложения ECO будут работать примерно в 1,5 раза медленней чем приложения, написанные без применения ECO. НО! тут есть несколько моментов, которые необходимо учитывать. Разарабатывая модель приложения, разработчик вынужден делать это с большей дисциплиной дизайна, что однозначно делает более быстрые решения. Это момент напрямую относящийся к быстродействию. Момент второй, который к быстродействию отношения не имеет. Разрабатывая приложение ECO, программист тратит примерно в 3-10 раз меньше времени.

Решение о том как, и с примененим каких технологий, создается то или иное приложение должно приниматься каждый раз, после оценки требований. Что в общем то понятно. Я еще раз напомню, что ЕСО всего лишь предоставляет возможности, а использовать их или нет - дело каждого разработчика.

Многозвенные приложения ECO

Задавался вопрос, можно ли сделать многозвенные и многопользовательские приложения c использованием ECO. Ответ - можно. Я это показывал на семинаре 2 декабря в Москве. Вопрос в понимании того, как устроено это многозвенное приложение. Основная черта в том, что в сервер приложений выносится PersistenceMapper, то есть тот компонент, который отвечает за хранение данных. А EcoSpace, как компонент приложения, отвечающий за хранение модели и, отчасти, логики является неотъемлемой частью клиентского приложения. Уж так устроено ECO и ничего с этим не поделаешь.
Второй вопрос - как же все таки сделать, что бы EcoSpace был на "сервере приложений". Ответ пока только один. Использовать Eco WebService. Тут сразу возникает много вопросов о необходимости такого подхода. И эти вопросы должны решаться в каждом конкретном случае.

ECO: Как перебрать в цикле все элементы ExpressionHandle

Для того, что бы перебрать в цикле все элементы ExpressionHandle надо воспользоваться тем, что свойство Element ExpressionHandle-а несет в себе реализацию интерфейса IObjectList. То есть цикл будет выглядеть примерно так:

Хм...

Что то я не понял. Читаем тут и тут
Кто же выиграл этот чертов конкурс, от которого вся страна стоит на ушах? По тем документам, которые проходят через меня с этим проектом связаны еще десяток контор.

Интересные мысли. Не мои.

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

Уникальность атрибутов сущностей в ECO

Каждый, кто занимался разработкой приложений с помощью ECO задавался вопросом, а как же сделать какой-нибудь атрибут сущности уникальным. В модели нет такого свойства атрибута.
Ответ лежит на поверхности. Ограничения задаются с помощью OCL. Для этого достаточно описать constraint на самой сущности. Например, ограничение, проверяющее уникальность имени у Customer:

Customer.AllInstances->select(name.sqlLikeCaseinsensitive(self.name))->exсluding(self)->size=0

есть несколько моментов на которые надо обратить внимание.
1. Нужно не запутаться с применение Self
2. OCL выражение в ограничении должно возвращать тип boolean
3. Ограничение НЕ проверяется автоматически. Где и когда проверять ограничения - дело разработчика

Мое отношение к ECO

После моего показа ECO в действии на семинаре Borland в декабре я прочитал несколько критических отзывов о моем выступлении (это отдельный разговор) и об ECO в частности.
Мне бы хотелось осветить СВОЮ точку зрения о том, что такое ECO и где его применять.
Сейчас доступна версия ECOIII. На мой взгляд только она стала более или менее пригодна для использования в повседневной жизни. Причина - нормальная реализация многопользовательской работы.
Для чего может применяться ECO? Для задач, которые:
1. Надо быстро сделать,
2. Которые надо часто менять.
3. Для небольших и средних задач, на 1-50 пользователей.
4. Для задач, для которых не слишком важна производительность.