Напрмер: на клиенте создаю объект User, у него есть свойтсво UserAction перечисляемого типа + у User еще есть LoginName и Password. Устанавливаем UserAction в что-нибудь типа uaLogin и засылаем на сервер в виде строки + засылаем тип объекта (что теоретически можно не делать).
Сервер получает эту строку, создает из нее обект, читает какую Action запустить и соответственно запускает. И посылает обратно тот же обект но с установленным свойством Logged.
Ууу как все запущено. А говорил новые технологии. С таким же успехом можно это сделать на TCP socket
И где здесь выигрыш от применения xml? Какая разница, вызывать ли
Code: Select all
CallSOAPRemote(Action action, byte[] serializedParameters);
Или
CallWinSockRemote(Action action, byte[] serializedParameters);
По моему никакой. Это что то вроде каменного топора с ручкой из углеволокна.
Возвращаясь к плохишам. Допустим в старорежимной системе выставлено наружу 500 функций. Что это дает хакеру? Ничего, он даже имен функций не знает, и форматов данных. То есть защита основана на незнании форматов данных. Это защитой считаться не может.
Теперь про ваши 2 функции: что поменялось по сравнению например с DCOM or RPC. Транспортный протокол. Вы будете использовать SOAP исключительно как транспорт а не как механизм вызова удаленных функций, для чего он собсвенно и был придуман.
Remoting был придуман для того что бы сделать прозрачным местонахождение вызываемого объекта. Я недавно делал приложение у которого есть 2 варианта поставки: remote server & local server. Для удаленного сервера функции вызываются удаленно а для локального локально. При этом код клиента одинаковый для обоих этих вариантов. Клиентский код не осведомлен, с каким экземпляром сервера он работает, удаленным или локальным. Если надо залогиниться то
Code: Select all
IUser user = Server.Instance.GetUser();
user.Login("vasia", 'password');
user.Name = "Petia";
user.Save();
В зависимости от того каким экземпляром сервера был проинициализирован синглтон Server, вызов пойдет либо на удаленную машину либо в локальную assembly. И если это удаленный сервер то будет возвращена Proxy, которая выглядит так же как и настоящий объект, только все вызовы перенаправляет на сервер и возвращает результат. Самое замечательное что не надо писать никакого кода для заглушки. .Net все сделает сам используя reflection.
Самое изящное в том что я одну и ту же assembly использовал как для реализации сервера удаленного, так и для локального. Удаленный вариант отличается только файлом конфигурации.
Недостатки вашей модели:
1. Надо иметь в каждом объекте исскуственное поле action.
2. Action будет постоянно и всюду модифицироватся по мере добавления и удаления функций.
3. На сервере будет громадный демультиплексор
Code: Select all
switch (typeOfObject) {
case "User"
switch(Action) {
case "login":
case "save"
case "load"
..
}
...
}
При каждом изменении функции его надо будет править вручную,
Назвать это современным подходом! Это было модно лет 10 назад.
4. Никакой проверки типов. Никакой проверки количества и типов параметров.
Только не говорите что можно сделать
Code: Select all
case "User" :
...
case "login"
if (params.length != 4 || params[0].GetType() == typeof(string)
|| params[1].GetType == typeof(int)
..... ну вобщем вы поняли)
5, прийдется писать 2 разных класса для клиента и для сервера для каждого бизнес обьекта!!!. Сервеный будет делать собсвенно бизнес логику, а клиентский
Code: Select all
class User {
public Save() {
CallRemote(Action.Save, this.GetType().Name, SerializeMe(this));
}
...
}
То есть ручное написание proxy. При большем количестве объектов и частых изменениях мало не покажется. Гарантирую.
Куда то консультант не туда рулит. Работаиь будет конечно (ведь работало же такое 15 лет назад), но вы подумайте на счет него, я ведь то же из Торонто
Шутка.
