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

А>как-то вы странно рассматриваете php негодится для целой тучи задач т.к. не может (без левых приблуд) иметь объекты после выполнения скрипта.
Ну — это его недостаток.

А>у вас же совершенно стандартная задача без извратов и нет ничего специфического, просто много скринов, много отчетов ...
Ну ни фига себе стандартная задача — это задачи — по ним системам люди кандидатские защищают по всему бывшему союзу. Не надо говорить — составить расписание занятий для вуза совсем не просто. Там совершенно точно методы ИИ нужны.

А>сложно это когда распределенная среда со взаимодействием с коболом банка парагвая на хим заводе с реалтайм системой а то, что много ... это только от ручек зависит.
Вот это — чисто технические проблемы, хотя тоже PHP здесь вряд ли себя оправдает. Много ,,, я не боюсь. Я боюсь сопровождения системы в которой этого много, а документации 0.Особенно если писал не я. А культура сопровождения без CASEа точно высокой не будет.

А>но если у вас оракл возьмите жабу
А>p.s. IMHO идеальный вариант — жаба бизнес объекты, пхп — веб морда.
Жаба — хороший вариант.
Вопрос я уже по-моему ставил — нахрена пользователю который, заранее известно, один работает с программой вебморда (тонкий клиент)?

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

M>Вопрос я уже по-моему ставил — нахрена пользователю который, заранее известно, один работает с программой вебморда (тонкий клиент)?

Аппетит приходит во время еды.
Я понимаю, если действительно была бы некая десктопная прога (winamp, например) там действительно трудно придумать зачем нужен тонкий клиент. Но когда пишется целая система, тонкий клиент обязательно будет к месту.

На вскидку: ввод пожеланий отдельных преподавателей к расписанию, публикация бета-версий расписания и т.д., и т.п.

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

DG>Аппетит приходит во время еды.
DG>Я понимаю, если действительно была бы некая десктопная прога (winamp, например) там действительно трудно придумать зачем нужен тонкий клиент. Но когда пишется целая система, тонкий клиент обязательно будет к месту.
DG>На вскидку: ввод пожеланий отдельных преподавателей к расписанию, публикация бета-версий расписания и т.д., и т.п.

Не я не про расписание. Расписание — отлично вписывается и по нему вопросов нет. Пожелания преподов можно рассматривать как экспертные оценки, графики учебного процесса как правила и т.д. и т.п.
Но вот скажем учебные планы — это история отдельная. Они как раз составляются каждым зав. кафедрой в отдельности. А уровень интерактивного взаимодействия (проверки на согласованность и все прочее ) там такой, что я, честно говоря, представить его в вебе просто немогу еще. Ну сделать это наверняка можно но какие там будут скрипты (как на клиенте, так и на сервере) — ой-ой-ой.
Стоит ли?

M>Но вот скажем учебные планы — это история отдельная. Они как раз составляются каждым зав. кафедрой в отдельности. А уровень интерактивного взаимодействия (проверки на согласованность и все прочее ) там такой, что я, честно говоря, представить его в вебе просто немогу еще. Ну сделать это наверняка можно но какие там будут скрипты (как на клиенте, так и на сервере) — ой-ой-ой.
M>Стоит ли?

Сложное редактирование — конечно, тащить в тонкого клиента не стоит, т.к. написать сложное редактирование в тонком клиенте — очень трудоемкий процесс. И самому конечно на такую бодягу лучше не подписываться. Хотя можно попробовать для редактирования просто хостить в IE .Net-контрол как ActiveX.

Я бы попробовал сделать так:
весь вывод данных (отчеты и т.д.) — делал бы через asp.net,
а сложный ввод данных через Windows Forms + remoting.

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

M>Не я не про расписание. Расписание — отлично вписывается и по нему вопросов нет. Пожелания преподов можно рассматривать как экспертные оценки, графики учебного процесса как правила и т.д. и т.п.
M>Но вот скажем учебные планы — это история отдельная. Они как раз составляются каждым зав. кафедрой в отдельности. А уровень интерактивного взаимодействия (проверки на согласованность и все прочее ) там такой, что я, честно говоря, представить его в вебе просто немогу еще. Ну сделать это наверняка можно но какие там будут скрипты (как на клиенте, так и на сервере) — ой-ой-ой.
M>Стоит ли?

1. еще раз, у вас сложность задачи лишь в объеме. ну много кода, ну сложная логика ... главное нет технических извратов.
2. скрипты бизнес логики будут точно такие как и без веба, разница лишь в способах представления, но это бизнес логику мало затрагивает. и совсем не трогает клиента.
нада будет прикрутите свинговый клиент, логика тут не причем.
3. чо за термин сложное редактирование ? в вебе один не достаток, нет сложных контролов (есть левые разработки), т.е. нет грида и т.п. отсюда следует что фиг гапишешь апликуху для оператора кот набирает 100 символов в секунду и не юзает мышь .. но опять же такого и не требуется. хотя люди в вебе практически ворд реализовали.
4. веб = маштабирование, новый офисс в израиле, декан сломал ногу, хочет из дому рулить, веб сервис для соседнего универа и т.п.

Gt_

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

DG>Сложное редактирование — конечно, тащить в тонкого клиента не стоит, т.к. написать сложное редактирование в тонком клиенте — очень трудоемкий процесс. И самому конечно на такую бодягу лучше не подписываться. Хотя можно попробовать для редактирования просто хостить в IE .Net-контрол как ActiveX.
DG>Я бы попробовал сделать так:
DG> весь вывод данных (отчеты и т.д.) — делал бы через asp.net,
DG> а сложный ввод данных через Windows Forms + remoting.
DG>Вводить данные нужно не многим, а вот смотреть на данные нужен почти всем.
DG>И хочется сразу делать так, чтобы эти все данные можно было получать простым способом.

Спасибо. Мое мнение почти целиком совпадает с вашим.
Вопрос вот еще какой — не могли вы привести примеры проектов реализованных таким способом. И еше порекомендуйте — хорошие книги по дотнету не для начинающих программистов. Желательно чтоб вопросы проектирования (специфика проектирования дотнет-приложений) там тоже освещались.
Спасибо!

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

А>1. еще раз, у вас сложность задачи лишь в объеме. ну много кода, ну сложная логика ... главное нет технических извратов.

Технических извратов действительно нет — и наша задача сделать чтобы и не было. Сложная логика да. Еще раз говорю — основная причина по которой не хочу использовать PHP — отсутствие caseов (мне они не известны). Если вам известны дайте ссылочку чтоли.

А>2. скрипты бизнес логики будут точно такие как и без веба, разница лишь в способах представления, но это бизнес логику мало затрагивает. и совсем не трогает клиента.
А>нада будет прикрутите свинговый клиент, логика тут не причем.

Согласен.

А>3. чо за термин сложное редактирование ? в вебе один не достаток, нет сложных контролов (есть левые разработки), т.е. нет грида и т.п. отсюда следует что фиг гапишешь апликуху для оператора кот набирает 100 символов в секунду и не юзает мышь .. но опять же такого и не требуется. хотя люди в вебе практически ворд реализовали.

Да-да именно так сложные контролы, интерактивные подсказки (не то ввел, много ввел — дораспредели такуюто нагрузку, освободи лучше этот предмет) и прочее. Не спорю — можно реализовать, но явно громоздко будет. Стоит ли игра свеч?

А>4. веб = маштабирование, новый офисс в израиле, декан сломал ногу, хочет из дому рулить, веб сервис для соседнего универа и т.п.
а)Ну офис в Израиле вряд ли понадобится ближайшие лет 20.
б)Если декан заболеет (тем более ногу сломает) — ему вряд ли захочется решать какие-то рабочие вопросы. Кроме его заменить всегда могут.
в)Ну из дома и по диалапу в универ подключись да и работай хоть и не через веб.

Еще раз выводы: отчеты в веб (да вообще все готовые документы) — это фактически неоспоримая правильная идея. Ввод данных — оспоримая, но реализуемая.
PHP (ASP не дотнет) — ? Написано выше.
Java — нормальное решение.
.NET — для меня зверь новый. Не писал больших программ. Хочу узнать побольше.
Может еще что есть?

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

M>Вопрос вот еще какой — не могли вы привести примеры проектов реализованных таким способом.

Это обычно, внутрикорпоративные разработки, когда на первый план выходит "ехать", а не шашечки.


M> И еше порекомендуйте — хорошие книги по дотнету не для начинающих программистов. Желательно чтоб вопросы проектирования (специфика проектирования дотнет-приложений) там тоже освещались.

Хороших книг по проектированию, да еще по проектированию .Net-а не встречал.

зы
Сам ищу.

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


M>БД без поддержки ссылочной целостности — хуже для коллектива разработчиков непридумаешь.

mysql podderzhivzet celostnost tam gde eto nuzhno uzhe 2 goda
(hotya do sih por deystvitelno mozhno pri zhelanii zavodit tablichkii i bez takoii podderzhki)

M> Хранимых процедур там тоже нет (от этого и быстрая она).

Eto deistvitelnoo obeshaut tolko v 5-i versii naverno cherez god
no vse ravno ne ponyatno prichem tut skorost..