Нужно организовать доступ к БД.
Что выбрать?

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

А>Нужно организовать доступ к БД.
А>Что выбрать?
ADO.Net

Здравствуйте, Merle, Вы писали:
M>ADO.Net

Не пойдет, нужна 3-х уровневая архитектура

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

А>Не пойдет, нужна 3-х уровневая архитектура

Remoting или WebServices реально существуют в отличии от Indigo. В остальном выбор Remoting vs Indigo это выбор Объекты vs Сервисы

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

TK>Remoting или WebServices реально существуют в отличии от Indigo. В остальном выбор Remoting vs Indigo это выбор Объекты vs Сервисы

Вообще-то я думал, что Indigo тоже предоставляет доступ к серверным объектам....
Ошибаюсь?

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

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

А>>Не пойдет, нужна 3-х уровневая архитектура

TK>Remoting или WebServices реально существуют в отличии от Indigo. В остальном выбор Remoting vs Indigo это выбор Объекты vs Сервисы

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

MC>Если использовать ремотинг в режиме Singleton то их разница сокращается тока до разницы в названиях.

Разница кардинальная. В веб-сервисах enpoint строго зафиксирован. Удалённо вызываются только те методы, которые прописаны в WSDL.

Через Remoting удалённо вызываются любые методы наследников MBR, стоит случайно его передать.

MC>Вобщемто я сейчас использую стателесс Ремотинг(Singleton)

Похоже, ты имел в виду Singlecall

Во всяком случае, модель веб-сервисов ближе к Singlecall

MC> а клиентам говорю что если им захочится юзать индиго, то для порта надо будет добавить дополнительные атрибуты в контакторе и все.

Вообще-то Microsoft официально говорит, что Indigo/WCF несовместимо с Remoting по протоколу.

Если код написан "в стиле SOA", то переделать его под WCF/Indigo будет несложно.

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

MC>>Если использовать ремотинг в режиме Singleton то их разница сокращается тока до разницы в названиях.

M>Разница кардинальная. В веб-сервисах enpoint строго зафиксирован. Удалённо вызываются только те методы, которые прописаны в WSDL.

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

M>Через Remoting удалённо вызываются любые методы наследников MBR, стоит случайно его передать.

MC>>Вобщемто я сейчас использую стателесс Ремотинг(Singleton)

M>Похоже, ты имел в виду Singlecall

M>Во всяком случае, модель веб-сервисов ближе к Singlecall

Лично я использую синглтон, для меня это урощенный кеш . Так что именно сиглтон . Хотя для текщей постановки это не сущетвенно, главное чтобы состояния небыло.

MC>> а клиентам говорю что если им захочится юзать индиго, то для порта надо будет добавить дополнительные атрибуты в контакторе и все.

M>Вообще-то Microsoft официально говорит, что Indigo/WCF несовместимо с Remoting по протоколу.

См. п 1.

M>Если код написан "в стиле SOA", то переделать его под WCF/Indigo будет несложно.

Во-во и я про тоже. Хотя в следующий раз буду оперировать понятием SOA, а не доморощенными описаниями .

M>>Разница кардинальная. В веб-сервисах enpoint строго зафиксирован. Удалённо вызываются только те методы, которые прописаны в WSDL.

MC>Разница, не в техническом плане, а в идеологическом. Не существенно какой протокол, а что я могу с ним сделать и сколько кода мне придется переделать на клиенте и сервере. Если бы задача стояла четче, ну например четко надо дистнциировать типы и их состояния, то тогда да.

Хм, не очень понимаю, что ты в данном случае имеешь в виду.

Есть большая разница и идеологическая, и техническая. Идеологическую хорошо выразил TK: объекты vs. сервисы [SOA].

Техническую тоже сложно не заметить, isn't it?
Другие протоколы, механизмы управления, модель расширения, совместимость.


Я к тому, что эти детали важны на раннем этапе. Нельзя просто сказать: тут мелкие несущественные различия.

M>Есть большая разница и идеологическая, и техническая. Идеологическую хорошо выразил TK: объекты vs. сервисы [SOA].
M>Техническую тоже сложно не заметить, isn't it?
M>Другие протоколы, механизмы управления, модель расширения, совместимость.

Он имеет в виду, что если на базе remoting'а строится stateless сервер приложений, то получаются, фактически те же сервисы, ну и что, что адресуются они ObjRef'ами?

При переходе к вебсервисам или индиге потребуется только слой прокси подменить — прикладной код останется тем же.

iT>Он имеет в виду, что если на базе remoting'а строится stateless сервер приложений, то получаются, фактически те же сервисы, ну и что, что адресуются они ObjRef'ами?

Ну как то есть какая разница! Ну как то есть ну и что!

Чтобы Remoting был сервисами нужна вдумчивая внутренняя работа, самоограничение и высокая степень концентрации. Одно неаккуратное движение — и вы отец


iT>При переходе к вебсервисам или индиге потребуется только слой прокси подменить — прикладной код останется тем же.

Если типы данных передаются только примитивные, то ты прав.

А если Hashtable? А если объект с событиями?

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

TK>Remoting или WebServices реально существуют в отличии от Indigo.

Ну почему? Январский CTP вышел под лицензией GoLive, так что можно попробовать рискнуть.

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

А>Не пойдет, нужна 3-х уровневая архитектура
Тогда БД здесь не причем...
Технически и идеологически все более-менее описали, а с точки зрения мировой революции — индига (правильное имя WCF) это наше всё, то есть будущее, но вот на сколько светлым оное будущее окажется, сие тайна великая есть. (хотя обещают горы златые)
С другой стороны, remoting технология проверенная, заработавшая определенную репутацию, с кучей примеров использования и умудренных опытом краеведов под рукой, но MS считает remoting не самой лучшей идеей и потихоньку от нее отпинывается...
Так что выбирай, но осторожно, но выбирай.

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

M>Технически и идеологически все более-менее описали, а с точки зрения мировой революции — индига (правильное имя WCF) это наше всё, то есть будущее, но вот на сколько светлым оное будущее окажется, сие тайна великая есть. (хотя обещают горы златые)
...
M>но MS считает remoting не самой лучшей идеей и потихоньку от нее отпинывается...

Интересно, откуда такие сведения. Может есть какие-то источники для таких посылов? Если есть, то можно ли получить на них ссылку?

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

А>Интересно, откуда такие сведения. Может есть какие-то источники для таких посылов? Если есть, то можно ли получить на них ссылку?
Сведения о чем? О том что WCF наше все или о том, что MS не очень рекомендует использовать ремотинг?
В любом случае сведения от сотрудников MS, да и вот одна из первых попавшихся цитат по этому поводу:
Из форумов на MSDN:

Current recommendations from Microsoft around Web Services vs. Remoting is that Web Services are a more viable long-term solution. Microsoft's Distributed Computing Group, which owns Web Services, .NET Remoting, WSE, DCOM, COM+, Enterprise Services, MSMQ, and Indigo, is encouraging a move toward Web Services and recommends avoiding implementations using .NET Remoting. Information can be found here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/introindigov1-0.asp

Windows Vista FAQ:

Q:What should I do to be ready to exploit Windows Communication Foundation when it ships?
A: ... NET Remoting-avoid or abstract using low-level extensibility such as .NET Remoting sinks and channels. ...

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

Вообще у ребят какие-то странные метания по этому поводу. Очевидно, они хотят, чтобы WCF заменило весь зоопарк средств по Distributed Computing Technologies, начиная с веб-сервисов и заканчивая MSMQ, но что-то им мешает...
Понятно, что совсем Remoting они не выкинут, но вот что они его дальше развивать не будут — можно утвержать довольно уверенно.

M>А если Hashtable? А если объект с событиями?

Hashtable — это не страшно. А если объект с событиями — то это уже никаким боком не сервис-ориентировано...

M>Понятно, что совсем Remoting они не выкинут, но вот что они его дальше развивать не будут — можно утвержать довольно уверенно.

Вопрос спорный. Это зависит от того, как пойдет то, что они двигают сейчас. Правда, двигать они умеют
Но Remoting сейчас уникален как .net-based технология распределенного взаимодействия объектов.
И приверженцы этого подхода быстро никуда не денутся...

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

iT>Но Remoting сейчас уникален как .net-based технология распределенного взаимодействия объектов.
iT>И приверженцы этого подхода быстро никуда не денутся...
Ну WCF и так будет уметь все то, что умеет Remoting и даже немножко больше... Плюс к этому, MS в принципе не очень приветствует именно такой подход, сколько бы приверженцев у него не было, сейчас рулят SOA и ковровое бомбометание...

M>>А если Hashtable? А если объект с событиями?

iT>Hashtable — это не страшно. А если объект с событиями — то это уже никаким боком не сервис-ориентировано...

Но и Hashtable в веб-сервис не пролезет. Тонкостей куча

iT>И приверженцы этого подхода быстро никуда не денутся...

Ну делись же куда-то приверженцы структурного программирования.