Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.
Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

Тут я сумбур написал, вот выдержки:
1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged (я знаю примеры объектных баз на .net, но хочеться знать ваше мнение). То есть подходит ли c# для написания баз данных, работающих с крупными массивами данных? Сомнения у меня в gc есть, не будет ли тормазить выборки/операции с базой?
2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

p.s. если это баян, жестоко извиняюсь.

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

S>1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged

Можно то оно можно. Только это отдельный огромный проект. Если конечно подходить к делу серьезно.

S>2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

Можно. Вот только на счет летало — это больше от алгоритмов зависит.

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

VD>Можно то оно можно. Только это отдельный огромный проект. Если конечно подходить к делу серьезно.
Я наверное не до конца выразил свою мысль: база задочена под erp, архитектура есть (не зависит от языка, вообще планировалось делать всю на с++), сложность там не сильная. Опять повторюсь, база затачивается под требования erp, но выборки совершаются как и у всех баз. Т.е. создается объект -> читает свои данные с диска -> посылается клиенту (это я утрировано, чисто пример). Вот тут всплывает GC, если выборка пришла на 1000 объектов, то они же будут весеть какое-то время в памяти сервера (хотя на c++ это можно мигом оптимизировать) после обработки, и память кушать... Просто я профан в c#, азы знаю, но вот практики никакой. Не будет ли грохать производительность/память GC?

VD>Можно. Вот только на счет летало — это больше от алгоритмов зависит.
Это ладно. Я впринципе понял, что можно. Но вот база...

Позволю себе высказать несколько мыслей относительно ваших опасений.
(Не в качестве саморекламы, а просто чтобы оценить опыт — последний год работаю на c#. Проект весьма тяжел и охоч до памяти. До этого больше 10 лет писал на плюсах)

1) "GC тормозит". Это миф. Он не тормозит. По крайней мере чтобы это стало заметно. Система поколений в GC работает просто "на ура". Более того, поскольку пямять теперь — managed, то возможно использование инструментария для конторля за использованием памяти (например, .NET memory profiler). С использованием этого инструментария можно поймать перерасход памяти и улучшить критические алгоритмы. С++ такие возможности анализа и не снились. Общий результат — только выигрыш.

2) Если сервер работает под .NET, то и коиенту разумно быть .NET. В противном случае гарантирован недетский секс (IMHO). Машины класса PIII-500 128mb потянут только очень легкие .NET приложения.

3) Если систему планируется поддерживать хоть сколько-нибудь лет, а не "написал, получил денег и забылкак кошмарный сон" — то .NET подходит сейчас лучше всего. Во-первых, под .NET писать и сопровождать проще и легче. Что на проектах размером "средний или чуть больше" в сумме будет уже IMHO экономически выгоднее (учитывая изучение новой технологии, инструментария, etc.) Во-вторых, ставка MS сейсчас идет на .НЕТ. Все остальное объявлено "deprecated"

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

S>Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.

Принципиально реализовать-то можно. Но в разработке любого продукта (в том числе и ЕПР системы) главенствует гораздо более интересный момент, чем сокрость выполнения программы — конечная стоимость.
И самым принципиальным вопросом для стороны-разработчика является ее МАХ, а для стороны-клиента ее MIN. Из текущего вопроса не очевидно на каком фланге находится Shhady. Если ближе к MAX — однозначно native, если к MIN — однозначно managed (и совершенно не обязательно .NET — это может быть Java, SmallTalk, etc)
Хотя, конечно, это- экстремумы. Можно (даже нужно) смешивать разнообразные подходы.

Но совет, который я хотел бы озвучить, звучит так: Модули/части, требующие усиленного мейнтененса -> managed (ибо гораздо!!! дешевле: ибо CPP обезъянки есть редкий и исчезающий вид, требующий хорошего обращения и дорогих витаминов), маломеняющиеся, но имеющие ограничения по ресурсам (скорости, памяти, выч. мощи) -> unmanaged.

S>Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

Дело в том, что может оказаться так, что по конечной стоимости было бы проще заменить эти P3 на P333 и писать managed код, чем пытаться сотворить все на managed.
К тому же стоимость бутерброда с колбасой + время, натраченное на его хавание, есть величина гораздо меньшая, чем стоимость нормального "unmanaged" программера + два бутерброда с черной икрой, необходимых ему для "норамьной" работы

S>Тут я сумбур написал, вот выдержки:
S>1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged (я знаю примеры объектных баз на .net, но хочеться знать ваше мнение). То есть подходит ли c# для написания баз данных, работающих с крупными массивами данных? Сомнения у меня в gc есть, не будет ли тормазить выборки/операции с базой?
Можно, но, думаю, не стОит. База данных — нет тот продукт, который часто изменять и поддерживать приходится (я имею ввиду код, а не саму базу)

S>2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

Обективных причин, не позворляющих сделать это, я не вижу.

S>p.s. если это баян, жестоко извиняюсь.
Этому баяну уже n лет, но пока никто на нем нормально не сыграл

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

S>Я наверное не до конца выразил свою мысль: база задочена под erp, архитектура есть (не зависит от языка, вообще планировалось делать всю на с++),

Если выбор между C++ и C#, то даже думать не нежно. Однозначно выбирайте Шарп. Писать серверы на плюсах — это одно мучение. Основное время будете тратить на вылов багов. Причем вылезуть они когда система уже будет работать. Все эти утички памяти и т.п.

С производительснотью в худшем случае вы проиграете 20-30 проценов. Но в надежности выиграете намного больше.

Здравствуйте, Shhady, Вы писали:
VD>>Можно то оно можно. Только это отдельный огромный проект. Если конечно подходить к делу серьезно.
S>Я наверное не до конца выразил свою мысль: база задочена под erp, архитектура есть (не зависит от языка, вообще планировалось делать всю на с++), сложность там не сильная.

Вы и СУБД хотите сами написать на С#?
или всеж только клиентов?

S> Опять повторюсь, база затачивается под требования erp, но выборки совершаются как и у всех баз. Т.е. создается кушать... Просто я профан в c#, азы знаю, но вот практики никакой. Не будет ли грохать производительность/память GC?

А не боязно без практики браться за такой большой проект?

VD>>Можно. Вот только на счет летало — это больше от алгоритмов зависит.
S>Это ладно. Я впринципе понял, что можно. Но вот база...

что база то?

Здравствуйте, xvost, Вы писали:
X>2) Если сервер работает под .NET, то и коиенту разумно быть .NET. В противном случае гарантирован недетский секс (IMHO).

В чем будет секс?
И не совсем понятно как сервер связан с клиентами?
Зачем им обоим нет?

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

PPA>Здравствуйте, Shhady, Вы писали:
VD>>>Можно то оно можно. Только это отдельный огромный проект. Если конечно подходить к делу серьезно.
S>>Я наверное не до конца выразил свою мысль: база задочена под erp, архитектура есть (не зависит от языка, вообще планировалось делать всю на с++), сложность там не сильная.

PPA>Вы и СУБД хотите сами написать на С#?
PPA>или всеж только клиентов?
Почему сам? Я что где то такое написал? Я только архитектор

S>> Опять повторюсь, база затачивается под требования erp, но выборки совершаются как и у всех баз. Т.е. создается кушать... Просто я профан в c#, азы знаю, но вот практики никакой. Не будет ли грохать производительность/память GC?

PPA>А не боязно без практики браться за такой большой проект?
Писать буду не я, но надо определиться инструментами.

VD>>>Можно. Вот только на счет летало — это больше от алгоритмов зависит.
S>>Это ладно. Я впринципе понял, что можно. Но вот база...

PPA>что база то?
Можно ли писать на c# то

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

S>Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

.NET Framework требует как минимум Win98, неужели даже Win95 еще работает?

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

X>Машины класса PIII-500 128mb потянут только очень легкие .NET приложения.
печально, но реалия такова

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

H>.NET Framework требует как минимум Win98, неужели даже Win95 еще работает?
А мне казалось и на w95 есть дистрибутив. W95 имею право на жизнь как и p3-533

Доброго времени суток!

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

S>Хотел поинтересоваться, можно ли реализовать erp систему на c#, которая может обслуживать до 1000 юзеров одновременно, да еще и распределенно (юзеры частично выполняют бизнес логику), да еще со своей объектной базой данных (то же на .net)? Клиенты smart'ы.

В данный момент тоже работем над подобным проектом!
Щас работает проект написанный на VB 6.0, база Access. База как как центральная, так и клиентские, очень сильно растут (обороты растут). Самая большая проблема щас это вывод в грид (тяжело конечно!!!)!
В перспективе клиентов на порядок больше, а с центральной базой будет работать примерно 300 человек!

S>Потянет ли c# по скорости и по требовательности (при 1000 юзеров то)? Да еще в наших суровых условиях (когда компы у юзеров ну максимум p3-533 с 128 ram да на w95-w98), да чтоб клиенты не сидели и бутерброды с колбасой хавали, пока клиентское приложение удасужит загрузиться?

С требованиями у нас конечно получше будет! Celeron 1.8, 512 ram. В переспуктивах конечно будет лучше.

S>Тут я сумбур написал, вот выдержки:
S>1. Можно ли на c# написать объектную базу, которая хотя бы не в 2 раза уступала бы написаной на unmanaged (я знаю примеры объектных баз на .net, но хочеться знать ваше мнение). То есть подходит ли c# для написания баз данных, работающих с крупными массивами данных? Сомнения у меня в gc есть, не будет ли тормазить выборки/операции с базой?
S>2. Можно ли написать rich (или smart, лично я считаю это лишь левым воскрешением идеи rich) клиент, который выполняют валидацию вводимых данных и некую бизнес логику. И главное чтоб работало приемлимо на p3-533 с 128 ram (лучше чтоб летало). И еще, клиент кэширует базу.

S>p.s. если это баян, жестоко извиняюсь.

В ценлом могу сказать что потянет! Правда со временем, конечно, технику стоило б заменить, но вот как уговорить клиента на это ( правда???).

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

X>>2) Если сервер работает под .NET, то и коиенту разумно быть .NET. В противном случае гарантирован недетский секс (IMHO).

PPA>В чем будет секс?
Одна из проблем будет в том, что потеряется возможность просто (не вообще, а именно без особых трудозатрат) проводить рефакторинг. Изменение протокола связи, формата данных, перенос части логики на клиент и обратно — если обе стороны на дотнет все это сильно проще и дешевле.

Ха, прикольный топик. Сам уже около полугода бъюсь над этим "филосовским" проектом.

Начну с того, что ЕЩЕ НЕ СУЩЕСТВУЕТ НИ ОДНОЙ ERP/CRM СИСТЕМЫ, РАЗРАБОТАННОЙ НА .NET! Что есть грустно и наводит на грустные размышления.

Проблема, как правило, в архитектуре и возможностях ADO.NET. Оно хорошо (по словам майкрософта) для веба, хорошо (по словам майкрософта) для серверных компонентов, но это АД для WinGUI-приложений.

Все дело в том, что майкрософт, судя по всему, решили просто убить wingui-разработку в том виде, в котором мы ее сейчас знаем. Об этом оворят несколько вещей — XAML, например, или убогий до невозможности такой основной элемент, как Grid. На примере грида можно увидеть насколько майкрософт плохо понимает назначение ТАКОГО элемента УИ при работе с данными в таких (ERP, CRM и более простых системах).

Разработать-то ЕРП можно, только вот не надо удивляться потом диким тормозам именно клиентской части и постоянной необходимости наращивать железо, но не на серверной части, как было раньше, а уже на клиентской.

Опять же, сами майкрософтовцы еще не смогли реализовать ничего толкового, в плане ЕРП, используя дотнеть.

ЗЫ: Не сервером и вебом едиными...

—

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Вот одно мое личное наблюдение: в таких топиках, как этот, НИКОГДА НЕ УЧАВСТВУЮТ ЛЮДИ ИЗ МАЙКРОСОФТ, а они ведь тута имеются!!! Даже приближенных к майкрософту не бывает. Все подобные вопросы остаются вегда либо без конкретного ответа, либо все ответы — домыслы отдельных людей.

Хотя может они никогда и не читают тут ничего? У них же есть архитекторы, нафига всяких "левых" девелоперов слушать?

АУ! ЛЮДИ ИЗ МАЙКРОСОФТА! СПУСТИТЕСЬ НЕНАДОЛГО НА НАШУ ГРЕШНУЮ ЗЕМЛЮ, ХВАТИТ ТАМ В ВЫСШИХ МАТЕРИЯХ ТУСОВАТЬСЯ! ЭТОТ ТОПИК — ВАМ!

—

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

BTA>Ха, прикольный топик. Сам уже около полугода бъюсь над этим "филосовским" проектом.


BTA>Начну с того, что ЕЩЕ НЕ СУЩЕСТВУЕТ НИ ОДНОЙ ERP/CRM СИСТЕМЫ, РАЗРАБОТАННОЙ НА .NET! Что есть грустно и наводит на грустные размышления.
Анологично

BTA>Проблема, как правило, в архитектуре и возможностях ADO.NET. Оно хорошо (по словам майкрософта) для веба, хорошо (по словам майкрософта) для серверных компонентов, но это АД для WinGUI-приложений.
Ты не поверишь, я долго ржал (чуть не плача), я ругался матом во всё горло, когда увидел smart клиенты, которые теперь продвигает ms (раньше были thin). Ну такого лецимерия, такого ... (незнаю как выразиться) я не ждал. MS лет пять, опять повторюсь, ms лет пять всех трахала идеей о thin (то есть браузерном) софте, что все корпаративные системы должны быть на браузерах (да и SAP туда же). Долой отдельные проги. Они это пропихивали во все щели, и что? Обратно к rich клиентам! Обратно к той идеи, которые они САМИ обсирали грязью (я всегда думал, что thin клиент — чушь), и теперь они такие спасители всего бизнес софта, сволачи. У меня есть книжка "архитектура корпоративных систем" (написана мелкомягким год назад), где черным по белому пишется, что надо делать упор на thin клиентов, настольные клиенты — в попу их. А теперь они говорят совершенно противоположное.

BTA>Все дело в том, что майкрософт, судя по всему, решили просто убить wingui-разработку в том виде, в котором мы ее сейчас знаем. Об этом оворят несколько вещей — XAML, например, или убогий до невозможности такой основной элемент, как Grid. На примере грида можно увидеть насколько майкрософт плохо понимает назначение ТАКОГО элемента УИ при работе с данными в таких (ERP, CRM и более простых системах).
Да да, убивали они её долго, щас же они её воскрешают, и типа это их заслуга.

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

BTA>Начну с того, что ЕЩЕ НЕ СУЩЕСТВУЕТ НИ ОДНОЙ ERP/CRM СИСТЕМЫ, РАЗРАБОТАННОЙ НА .NET! Что есть грустно и наводит на грустные размышления.

По непроверенной информации Navision 3.7 написан на .Net.

Здравствуйте, BlackTigerAP, Вы писали:
BTA>Все дело в том, что майкрософт, судя по всему, решили просто убить wingui-разработку в том виде, в котором мы ее сейчас знаем. Об этом оворят несколько вещей — XAML, например, или убогий до невозможности такой основной элемент, как Grid. На примере грида можно увидеть насколько майкрософт плохо понимает назначение ТАКОГО элемента УИ при работе с данными в таких (ERP, CRM и более простых системах).

Есть же сторонние разработки http://www.devexpress.com/
судя по демкам, их C# решение тормознее родного делфевого (иногда раза в 2),
но они наверное пока не занимались оптимизацией.

Здравствуйте, Shhady, Вы писали:
PPA>>Вы и СУБД хотите сами написать на С#?
PPA>>или всеж только клиентов?
S>Почему сам? Я что где то такое написал? Я только архитектор

Вы у своих девелоперов спрашивали что им предстоит сделать?
Что говорят?

S>>> Опять повторюсь, база затачивается под требования erp, но выборки совершаются как и у всех баз. Т.е. создается кушать... Просто я профан в c#, азы знаю, но вот практики никакой. Не будет ли грохать производительность/память GC?

PPA>>А не боязно без практики браться за такой большой проект?
S>Писать буду не я, но надо определиться инструментами.

С этим должны определяться разработчики, архитекторов производительность и сборка мусора не должна имхо волновать.
Если разработчики нули в шарпе, то браться за такой проект — самоубиство
Конечный пользователь не оценит, то что все сделано на модном нете-е, им нужно чтоб работала система в целом, и работала быстро.

VD>>>>Можно. Вот только на счет летало — это больше от алгоритмов зависит.
S>>>Это ладно. Я впринципе понял, что можно. Но вот база...

PPA>>что база то?
S>Можно ли писать на c# то

Клиентов можно — 100%.
СУБД на шарпе — имхо работать будет только теоретически

p.s.
А чем Вам готовые СУБД не подошли?