ASP.Net vs Java vs не знаю что еще.

← →
Тимохов © (2009-04-05 21:55) [40]

Пример работы с WinINet есть у Розыча на сайте. В принципе для понимания его примеров нужен небольшой бекграунд по знанию протокола HTTP. Я могу, если что проконсультировать. Изначально у Розыча не все понятно - иногда кажется, что он облажался (в этом HTTP не все очевидно на первый взгляд с передачей длины сообщения) :) Но при изучении RFC 2616 все становится на места.

В общем - все мои советы, это продолжение совета пользовать webservice.

← →
Petr V. Abramov © (2009-04-06 03:46) [41]

> 1. Доступ через браузер на сайты развит сейчас как никуда
> лучше. Сам знаешь.

угу, только если испльзовать веб-интерфейс, ради ввода 50 цифр на 500 байт придется грузить страницу на одзин мегабайт, и что там на отправке, не знаю. Грузиться это будет хз сколько, потому что объективно инет там может быть и формально бытрым, но реально фиговым, замкадье замкадских городов, ну не проложили/не восстановили там еще инфраструктуру, дело движется, но нельзя ждать пока оно там.

← →
Тимохов © (2009-04-06 05:28) [42]

Петь, ты фигню говоришь )

← →
Тимохов © (2009-04-06 05:46) [43]

Ладно, дабы не быть голословным про говорение тобой, Петр, фигни, конкретизирую...

Протокол HTTP имеет очень небольшой оверхед. Ну там заголовок - и все ))) Ну заголовок это байт 400 максимум. Обычно много меньше. Все остальное чистые данные. Возможно еще процент уйдет на кодирование данных - HTTP 1.1 обычно передает чанками (кусками) - тут еще есть немного оверхеда.

Все остальное - это фигня, которую ты говоришь. Я могу, кстати, понять, откуда такая фигня идет. Тебе, видимо, сказали, что ни один сайт не загружается в урюпинске хорошо. Ну ясный перец, под модем уже давно сайты не делают - ты попробуй gmail загрузить под gprs (загрузишь, но только в режиме HTML). К тому же - сайты давно не пишут с нуля, их делаю на цээмесках (CMS) - сам понимаешь, общее решение плохо работает в конкретном случае. Поэтому там сайты не грузяцо - потому как для его загрузки нужно 232 обращения к БД сделать.

Ты знаешь, Петр, я тоже раньше боялся веба - типа считал его чем-то недостойным знатока MSSQL (Oracle в твоем случае). Однако веб идет по миру, причем жестко идет (скоро забудем клиентов на чем-то еще, кроме как на ajax). Поэтому - не умничай, и не слушай галимые мнения о том, что веб - это всегда трехкратный оверхед. Все это защита от наступающего признания технологии ЧЕЛОВЕЧЕСТВОМ!!! (это я про HTTP)

Петя, телефон знаешь, адрес тоже заешь, заходи - просвещу.

← →
iZEN (2009-04-06 06:30) [44]

JAX-RPC, JAX-WS, JAX-RS.

"Enable REST with Web services, Part 1: REST and Web services in WSDL 2.0"
http://www.ibm.com/developerworks/webservices/library/ws-rest1/

"Создание REST-сервисов"
http://www.ibm.com/developerworks/ru/edu/x-restatompp/index.html

JAX-RS хорошо поддержан в NetBeans, так что вперёд и с пестней.

← →
b z (2009-04-06 10:36) [45]

> Petr V. Abramov © (05.04.09 12:06) [29]
> что-нить серьезнее акцесса там ставить жестоко и некуда,
> да и работников в филиалах по 5+ человеков
Есть експрес версии субд. На веб сервисах лично я не советую.
В текущем проекте клиенты сразу захотели толстых клиентов на окошках + веб сервисы, мотивируя скоростью. Вот сейчас, когда практически проект уходит в кандидат релиз, они наконец-то "уговорились" :) (на самом деле увидев разницу) именно на веб клиентов, а их много под разные задачи, а там где нужна интерактивность + рушечки, идем на silverlight, даже в будущем есть планы на surface, эх скорее бы :). Идя на веб серсисы появляются всякие другие моменты, такие как надежность, сохранность, .... отсюда могут понядобиться некие распределенные транзакции, неважно как и кем реализованные, и т.п., а это никак не способствует уменьшению трафика. ну и т.д.
Конечно же мне могут возразить, но все как всегда зависит от условий.

← →
clickmaker © (2009-04-06 12:45) [46]

> А дальше хош .ПТУ

а почему ПТУ, кстати?

← →
kaif (2009-04-06 15:04) [47]

Я бы попробовал именно ASP.NET для такой задачи. Во-первых управление сессиями и безопасность уже решены на уровне самой платформы. Во-вторых (и это немаловажно) все можно развивать в одном месте, а не бегать по филиалам. Все работают через браузер. Разумеется, если клиенты должны работать и автономно - этот вариант не подойдет. Но об этом уже говорилось. Я бы пошел на то, чтобы клиенты не могли работать локально. Пусть проводят инет - XXI век на дворе. Заказчика следует убедить поступить именно так. Издержек в любом случае будет в результате на порядок меньше, чем поддерживать и развивать какую-то распределенную систему приложений с репликациями (это - еще тьма противоречий).

← →
kaif (2009-04-06 15:30) [48]

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

Петр, посмотри на задачу как финансист.
Вот, допустим, у тебя браузер.
Из браузера можно печатать документы.
А можно купить по Microsoft Offic-у и в него экспортировать данные. Купить по офису на каждый комп из 5 человек - затраты нехилые. А можно ворованный офис юзать. Затраты при визите ОБЭП могут стать еще более нехилыми.

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

Даже если ASP.NET не нравится по каким-то причинам (например, новая версия появляется быстрее, чем успеваешь скачать и установить предыдущую), то можно дубовее - PHP+Apache. Идеальная связка. Только с безопасностью разобраться - и вперед.

← →
Petr V. Abramov © (2009-04-06 15:41) [49]

> kaif (06.04.09 15:04) [47]
> Пусть проводят инет - XXI век на дворе

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

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

в данном случае это не так.

> Даже если ASP.NET не нравится по каким-то причинам

да нравится, не нравится, сколько страница будет грузиться.

← →
kaif (2009-04-06 16:14) [50]

Ну, сам смотри.
Что за промзона такая без связи?
Я бы либо инвестировал в связь, либо вообще не инвестировал в эту промзону.
Хотя, впрочем, если в кризис кому-то нужно затраты не уменьшать, а увеличивать - флаг в руки.

На мой взгляд самое дешевое решение, если связи нет, как раз таки вообще отказаться от идеи информационной репликации финансовых и деловых частностей филиалов в центр. Финансовую отчетность нужно в этом случае полностью сделать автономной, но с грамотной и четкой, с определенными общими показателями. Раз в месяц пусть руководство филиала выбирается из своей тьмы-таракани на лыжах или на вездеходах (что там за МКАДом проехать может) и едет с этой отчетностью на дискетах в руках в Центральный Генеральный Офис для Консолидации. Много заработали для Офиса - Премия. Мало заработали - Нагоняй и Урезание Финансирования.

Если нет надежной связи, то бессмысленно и собирать информацию в центре. Это то же самое, как если Наполеон, не имея четкой связи с маршалом Неем вместо того чтобы поручить тому самому решать на месте снимет с того всякую ответственность, перенося решения в центр, не обеспеченный надежной информацией. Тогда Наполеон проиграет сражение. Собственно, Ватерлоо он так и проиграл. Он послал гонца, а тот не дошел. А Бонапарт рассчитывал на подкрепление в нужный момент. Не рассчитывал бы, не проиграл бы.

← →
kaif (2009-04-06 16:36) [51]

Слышь, Петр, а с чего ты взял, что страница 1 Мб будет? Сколько захочешь, столько и будет твоя страница. Вообще лучши, ИМХО, попробовать. Я бы поставил IIS в центре. У них есть выделенный IP, надеюсь? Поставил бы Framework. Второй. И повесил бы простенькую страницу с запросом к базе данных. С сеткой из 10 строк. Убрал бы из фирменного скрытого аспнетовского поля всю лишнюю инфу о состояниях компонентов (некоторые разработчики не догадываются, что так можно уменьшить размер страницы, надеюсь здесь таких нет). А потом поездил бы по филиалам, если у них телефона нет и посмотрел бы, настолько ли там медленно эта страница грузится, как ты говоришь. На этот эксперимент нужно всего 1 день усилий + книжка + эпсилон энтузиазизма, если даже ты вообще не знаком с ASP.NET. И нуль финансирования. Зато потом можно будет принять какое-то определенное решение. А что если результат вдохновит заказчика? Зато нуль администрирования на местах, полная прозрачность и масштабируемость системы. Плюс все метаданные, отчеты и документы можно в Москве, спокойно лежа на диване с бутылкой пива в зубах разрабатывать и внедрять, не выходя из дома.

← →
Медвежонок Пятачок © (2009-04-06 16:41) [52]

это надо постараться чтобы мегабайт был на асп странице.
либо теток туда в тифе вывесить, либо во вьюстэйте целиком гонять справочник БИК и КБК вместе взятые

← →
clickmaker © (2009-04-06 16:45) [53]

> либо во вьюстэйте целиком гонять справочник БИК и КБК вместе
> взятые

даже в этом случае размер страницы можно уменьшить, перекрыв LoadPageStateFromPersistenceMedium / SavePageStateToPersistenceMedium и применив там какое-нибудь сжатие

← →
kaif (2009-04-06 16:53) [54]

Тойнби полагал, что для того чтобы достичь какой-то цели нужно всегда ставить более возвышенную цель. Поднимись над задачей. Чего вообще хочет заказчик? К сожалению, часто приходится видеть картину, когда один человек задачу ставит, а другой финансирование выделяет. А третий решения принимает. На основе моды или интриг внутрифирменных.
ИМХО. Здесь есть только три варианта.

1. Потратить бабки с откатом и ничего не получить вообще. Тогда рекомендую разрабатывать пару лет систему репликаций и хитрую распределенную самописную платформую.

2. Повысить эффективность филиалов при минимальных затратах и минимуме гимора для клиентов (потребителей), зато с некоторым гимором для руководства филиалов. Тогда рекомендую внедрить самую простую и надежную систему локальной отчетности, а консолидацию потребовать, чтобы привозили руководители филиалов лично раз в месяц. Если приезжает один руководитель на ВАЗ2107 и у него в этом месяце на миллион продаж, а другой на Lexus-е, а у него в филиале одни убытки - делать выводы.

3. Минимум гимора для центра, минимальная себестоимость обслуживания, средняя эффективность бизнеса, нулевая обижаемость филиалов (что на браузер обижаться ?), максимум гимора для клиентов (потребителоей). Решение ASP.NET. Если интернета нет, клиент (потребитель) уходит ни с чем. Для тебя конкретно, Петр, это наилучшее решение.

Все ИМХО, разумеется.

← →
Petr V. Abramov © (2009-04-06 18:03) [55]

> Что за промзона такая без связи?
> Я бы либо инвестировал в связь, либо вообще не инвестировал
> в эту промзону.

промзона - это просто хмурое место, где расположена куча складов, заводов и т.п., имеющих разных хозяев и арендаторов. Если они договариваются между собой, то сообща вкладываются в инфраструктуру, а пока нет, живут как есть. В одиночку это не потянуть.
а инвестировать в то, чтобы несколько несколько десятков цифр несколько десятков раз в день гонять по гигабитному каналу, нелогично.
и не нужно тут никакую финансовую отчетность гонять, см. [0].

← →
Petr V. Abramov © (2009-04-06 18:08) [56]

> kaif (06.04.09 16:36) [51]

да мне проще попросить
> А потом поездил бы по филиалам, если у них телефона нет
> и посмотрел бы, настолько ли там медленно эта страница грузится,
> как ты говоришь. На этот эксперимент нужно всего 1 день
> усилий + книжка + эпсилон энтузиазизма, если даже ты вообще
> не знаком с ASP.NET.

да проще попросить их открыть сайт Подгорецкого :), он же вроде б на ASP?

← →
isasa © (2009-04-06 18:58) [57]

FrameWork + WCF на IIS, связь по TCP или HTTP с шифрованием или без ...

← →
iZEN © (2009-04-06 20:02) [58]

Ну, IIS я бы не стал никому советовать ставить. Эта штука потянет за собой всю инфраструтуру Windows в том числе сервера безопасности и обновлений (WSUS). Дальше — больше.

Для реализации Web-сервисов достаточно FreeBSD 7.1 + правильно настроенный PF + установленный Apache Tomcat v.6 (из порта). Как "промежуточная" база данных будет удобна Apache Derby (входит в Sun JDK для Windows под именем "JavaDB").
Разработка может вестись как в Eclipse, так и в NetBeans.

Рекомендую приобрести следующие книги, если выберете Java в качестве платформы:

• Кей С. Хорстманн, Гари Корнелл «Java 2. Библиотека профессионала, том 2. Тонкости программирования», 8-е издание, ISBN 978-5-8459-1482-8, 978-01-3235479-0
http://www.williamspublishing.com/Books/978-5-8459-1482-8.html

• Гери Д., Хорстманн К. «JavaServer Faces», ISBN 978-5-8459-1396-8
http://www.williamspublishing.com/Books/978-5-8459-1396-8.html

• Дей Нейси, Мандел Лоренс, Райман Артур «Eclipse. Платформа Web-инструментов. Разработка Web-приложений на языке Java», ISBN 978-5-91136-051-1
http://okc.ru:8080/okc/publish/imag.nsf/book/978-5-91136-051-1

← →
kaif (2009-04-06 20:47) [59]

Найди подходящий сайт на ASP.NET или сервлетах Java и попроси их попробовать его открыть. Может все не так страшно. Я сторонник реальных экспериментов при принятии такого рода решений.

← →
Petr V. Abramov © (2009-04-06 23:32) [60]

> iZEN © (06.04.09 20:02) [58]
> Ну, IIS я бы не стал никому советовать ставить. Эта штука
> потянет за собой всю инфраструтуру Windows в том числе сервера
> безопасности и обновлений (WSUS). Дальше — больше.

в центре вся эта страшная инфраструктура есть. При этом времени на ее обслуживание уходит около нуля на фоне проблем с принтерами.

← →
Petr V. Abramov © (2009-04-06 23:40) [61]

> kaif (06.04.09 20:47) [59]
> Найди подходящий сайт

прямые аналоги на весь инет не висят и висеть не могут, хотя задача не из серии суперновых.
во-вторых, для меня не очевидно(в силу чайництва), что разработка на ASP.Net будет проще, чем гонять над http какие-то очевидные вещи.

← →
Городской Шаман (2009-04-06 23:42) [62]

> Petr V. Abramov © (06.04.09 18:03) [55]

Ну если хотите что-то надёжное и очень лёгкое то http://www.eldos.com/msgconnect/ . Обмен данными через сжатый zlib-бом XML файл.

← →
kaif (2009-04-07 02:11) [63]

2 Petr V. Abramov © (06.04.09 23:40) [61]

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

Попробуй сам. Язык C# осваивается быстро и он довольно красив. Идеология ASP.NET страницы похожа чем-то на дельфийскую. Имеется форма, на нее кладутся компоненты. Образуется дерево тегов (XML). Свойства каждого компонента описываются атрибутами соответствующего тега. Можешь даже разметить страницу обычной HTML-таблицей и напихать компоненты внутрь ее ячеек.

Как и в Delphi, на события можно вешать обработчики. И обработка пишется на человеческом языке C#, что очень приятно. Все довольно стройно и просто. При поступлении каждого HTTP-запроса подсистема ASP.NET генерит дерево компонентов страницы в памяти, создавая объекты рантайм.

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

← →
Иа (2009-04-07 05:53) [64]

.NET 3.5, C# Winforms + C# WCF service

Скорость написания и удобство родного клиента + удаленное соединение.

← →
isasa © (2009-04-07 08:39) [65]

iZEN © (06.04.09 20:02) [58]

Ну, IIS я бы не стал никому советовать ставить.

Не нравится IIS, сервисы можно оформить консольным приложением.
Работает на IIS Win XP при выключенном обновлении и т.п. Не морочь голову.
Для работы необходим только .NET Framework 3.0(3.5) и MTS.

Работает как с компонентами MS, так и "нативными", например, от Oracle

← →
Petr V. Abramov © (2009-04-07 10:11) [66]

> kaif (07.04.09 02:11) [63]
> Как и в Delphi, на события можно вешать обработчики. И обработка
> пишется на человеческом языке C#, что очень приятно.

а что будет происходить (по шагам), при следующей нехитрой последовательности действий:
1. в колонке 1 набираем: 789-5, жмем enter
2. 789-5 отправляется в базу
3. база отвечает "пельмени вегетарианские особые"
4. "пельмени вегетарианские особые" появлятся в колонке 2
5. курсор уходит на колонку 3

у меня большое подозрение(возможно, ты его развеешь), что на п.4 весь этот html опять совершит путешествие москва-урюпинск и между 1 и 5 можно будет чаю попить.

← →
Petr V. Abramov © (2009-04-07 10:25) [67]

> Городской Шаман (06.04.09 23:42) [62]

а это кто-нибудь использовал?

← →
Медвежонок Пятачок © (2009-04-07 10:36) [68]

При энтере уйдет только постдата контролла (если автопостбак у контрола выставлен)
Обратно - новая страница уже с пельменями

> При энтере уйдет только постдата контролла

ну это логично

> Обратно - новая страница уже с пельменями

я так понимаю, страница целиком?

целиком, хотя возможны варианты с аяксом

> Petr V. Abramov (07.04.2009 10:40:09) [69]

Что бы не целиком, то надо использовать расширения AJAX с UpdatePanel - тогда столько сколько надо, поскольку вроде может быть несколько UpdatePanel

> Anatoly Podgoretsky © (07.04.09 11:04) [71]
> бы не целиком, то надо использовать расширения AJAX с UpdatePanel

а Visual Studio об этом подозревает?

Подозревает, надо только дополнительно установит.
ASP.NET оно как Дельфи - компоненты, свойства, методы, пакеты.
Исключение расширяемость, можно даже добавлять даже свои языки, но можно и убирать, как это произошло с J++ и C++, остались VB.NET и C#

← →
kaif (2009-04-07 11:21) [74]

Аякс можешь попробовать. Пусть народ в филиале в google поищет что-нибудь. Google по нажатиям клавиш отрабатывает поиски в словаре и отображает выпадающий список. Чаю я лично попить не успеваю. Принцип Аякса в том, что HTTP-запрос отрабатывается без перезагрузки страницы. Я попробовал сделать Аякс руками, у меня заработало лишь под одним браузером. Когда я попробовал Аякс, встроенный в ASP.NET, у меня сразу заработало под 3 браузерами. Так как ASP.NET в лице Microsoft берет на себя заботу о том, какому браузеру какую реализацию Аякс подсунуть. Обрати внимание на этот факт.

Я понимаю, что именно тебя волнует. У меня была идея насчет ввода данных. На странице кнопки, Java-скрипт добавляет поля для ввода строк накладной без перезагрузки формы, локально в браузере. Товары ищутся по коду или наименованию в удаленном справочнике при помощи Аякс. Затем вся форма отправляется на сервер субмитящей кнопкой. На стороне сервера определяется, сколько было послано полей в форме и на нормальном C# написано обращение к базе данных и соответсвующие модификации данных. Обрати внимание, ASP.NET имеет специализированные компоненты доступа (DataSource) к разным базам данных. То есть провайдер для ORACLE имеет свои особенные методы ORACLE, а провайдер для InterBase (я его, кстати тоже пробовал) или MS SQL - свои, заточенные под каждый сервер методы. Это не ODBC и не JDBC.

> kaif (07.04.09 11:21) [74]
> На странице кнопки, Java-скрипт добавляет поля для ввода
> строк накладной без перезагрузки формы, локально в браузере.
>

я так думаю, Devexpress и компания это уже давно сделали, если даже нет, подпилить не так сложно будет, навскидку кажется.

← →
kaif (2009-04-07 11:31) [77]

Petr V. Abramov © (07.04.09 10:11) [66]

> kaif (07.04.09 02:11) [63]
> Как и в Delphi, на события можно вешать обработчики. И обработка
> пишется на человеческом языке C#, что очень приятно.

а что будет происходить (по шагам), при следующей нехитрой последовательности действий:
1. в колонке 1 набираем: 789-5, жмем enter
2. 789-5 отправляется в базу
3. база отвечает "пельмени вегетарианские особые"

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

1. в колонке 1 набираем: 789-5, жмем enter
2. 789-5 отправляется в базу
3. Локальная база отвечает "пельмени вегетарианские особые". Не факт, что пельмени с этим кодом есть в центральной базе. Возможно их давно удалили, так как их никто не покупает. И их код присвоили другим пельменям. Или наоборот. В центральной базе они уже есть. Другой филиал им уже присвоил код 666 и успел среплицироваться. А твой филиал получит Unique or primary key violation при попытке создания дубликат в процессе репликации завтра. Или не получит violation, но зато центр получит дубликат. А чтобы такого не было, Центр введет административный приказ, запрещающий локально справочники заполнять. Только из центра получать. И склад будет не просто чай пить, ожидая Аякс для одного кода пельменей. Он будет чай пить и на обед обед и на ужин успеет, ожидая, когда, наконец, репликация с Центром произойдет и все обновления всех справочников придут со всех филиалов, независимо от того, нужны они сейчас или нет.

> kaif (07.04.09 11:31) [77]

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

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

← →
kaif (2009-04-07 11:51) [79]

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

Когда я познакомился с технологией Java сервлетов и Tomcat я загорелся на то, чтобы попробовать реализовать это таким образом. Но в Tomcat ряд моментов меня безумно раздражал. Например все эти версии JDK. Да и вообще этот тупой построчный парсинг JSP в сервлет с компиляцией и перезагрузкой HTTP-сервера... Потом я заинтересовался ASP.NET. И когда стал изучать, я пришел к выводу, что это и есть то, что нужно для подобной задачи. Именно для задачи Центр+Филиалы. Я все же исповедую религию чистых клиент-серверных систем. Все таблицы должны быть в одном месте. Работать нужно через браузер.

Мне говорили о JSF как аналоге ASP.NET. Типа тоже компоненты. Не пробовал, не знаю. Знаю лишь, что ASP.NET, например, имеет встроенную поддержку пользователей и ролей на уровне архитектуры. То есть можно написать просто свой класс провайдера логинов и ролей (я это проделал и это сразу заработало), который хранит все это в каком-то особенном месте (я в своих собственных таблицах в InterBase хранил так как мне удобно) и ASP.NET благодаря прозрачности архитектуры провайдеров сама автоматически отключала или делала недоступными те пункты меню, которые я не хотел, чтобы пользователи с определенными ролями видели. А коду я написал всего на пару страниц при этом.

> kaif (07.04.09 11:51) [79]
> Все таблицы должны быть в одном месте. Работать нужно через
> браузер.

ну тут лоб расшибать тоже нельзя, в Казахстане это все равно будет дублироваться в местный 1С. И не в Казахстане тоже, если филиал - отдельное юрлицо, что часто бывает.

ASP.Net vs Java vs не знаю что еще. Найти похожие ветки