ВМоисеев>Я отказался от вебсервисов - .Net Remote Service поверх IIS более практичны.

Насколько я понял из МСДН, ремотинг-живой труп. Мелкософт теперь позиционирует его лишь как средство коммуникации между АппДоменами (внутри одного процесса) или для поддержки нестандартных транспорных протоколов.

Имхо связываться с ним сейчас уже не стоит, он вместе с ДКОМом медленно удаляется в страну вечной охоты :)

Простой рабочий Tygra
Говорят, IIS - слабое место MS в плане безопасности...
Проблем нет, юзай апаш :)

Простой рабочий
1) Произойдёт полное привязывание к конкретному СУБД и, если назреет необходимость поменять СУБД - мы просто не сможем этого сделать
Имхо независимость от БД реально нужна только в 2 случаях: 1) если вы разработчик тиражируемого приложения, тогда это может расширить рынок сбыта 2) Если СУБД с которой вы работаете не Oracle, MS SQL или DB/2 - тогда рано или поздно придется думать о замене СУБД.

Простой рабочий
2) Резко увеличится потребность сервера в оперативной памяти и частоте процессора. Почему именно мою систему ставили на предприятия - достаточно было дохлых серверов или даже рабочей станции с WinXP в качестве сервера.
Сервер приложений не будет быстрее и эффективнее промышленной СУБД, аминь. Сервера приложений теоретически более масштабируемы. Но до вопросов связанных с масштабированием надо еще дорасти. Потребности в масштабировании обычно сильно преувеличиваются поставщиками соответствующих платформ :).

Простой рабочий
3) Программеру, кроме знания VB.Net/C# необходимо ХОРОШО знать T-SQL.
TSQL хорошо знать придется по-любому. А вот если сервер приложений будет делать работу сервера БД (изоляция, блокировки, сортировка, джойны, фильтры итп) то разработчикам кроме собственно бизнес-логики придется задумываться о действительно сложных вещах.
А теперь подумайте об отладке и поддержке вашего сервера приложений. Насколько я понимаю вы работали с MS SQL. Аналог EnterpriseManager'а вы еще сможете написать, но представьте во что обойдется вам инструмент-аналог SQLProfiler'а ?

Простой рабочий
tygraПодсказка: а если завтра нужно будет к БД дать доступ и извне, и изнутри, вы будете и в ехе-шнике, и в вебсервисах, и еще хрен знает где дублировать (и менять каждый раз!!!) всю логику??? Очень хорошо, поздравляю, но мне такого даже за деньги не нать. :)) Я уж лучше в одном месте поправлю - а в трех заработает :))

Я тоже хочу в одном месте - в сервере приложений. Это и подразумевается в трёхзвенке.
Имхо ключевая проблема серверов приложений - в отсутствии устоявшегося стандартизированного интерфейса к ним.
СУБД- очень зрелая технология используемая уже более 40 лет.
Использовать любую СУБД из любого приложения не проблема наверное уже лет 20.
С серверами приложений ситуация диаметрально противоположна.
Полный разброд и метания. У каждого апп-сервера свой интерфейс не совместимый более ни с чем.
Возможно веб-сервисы что-то изменят в этой ситуации, но сейчас имхо ничего еще не устоялось и каждые полгода меняется.
Покрутите в голове случаи использования вашей системы:
Пакетные задания из под шедулера-?, печатные формы для пользователей-?, ОЛАП-?, интеграция с офисными приложениями-?, распределенные транзакции-?, интеграция с другими системами-?
Из-за нестандартности интерфейса самопального сервера придется самому писать тонны кода, вместо использования стандартных решений.
А через годик выйдет Индиго, еще через парочку какое-нибудь Индиго-2, еще через год супер сервер окажется малопонятной системой работающей на устаревшей технологии, доступ к которой можно получить только через не поддерживаемый ни одним поставщиком интерфейс.

tygraЗЫ Логика в вебсервисах - это вообще кошмар!

А не могли бы поделиться конкретными причинами такого мнения.
Вопрос меня сейчас реально интересует в практическом плане - у нас тут активно дискутируются варианты типа толстый клиент - веб-сервис(с Б\логикой)- БД vs браузер-IIS-БД(с Б\логикой) и тому подобное.