Есть БД. Нужно сделать клиента к ней (Desktop клиент). Клиент должен быть способен
работать не только в локалке но и в инете.
Раньше делал так:
Для клиента в БД создаётся набор необходимых хранимок,
которые позволяют забирать нужные данные из БД. И сохранять в БД.
Фактически это была бизнес логика.
Для обмена данными с клиентом через инет/локалку, создаётся WebService —
фактически является обёрткой над хранимками — тупо вызывает их,
получает данные и РУЧНЫМ СПОСОБОМ преобразует их в DTO ну и результат
сериализуется в XML и передаётся на клиент.
На клиенте это DTO ручным способом (явно вызывая конструкторы) преобразуется
в BO. Ну и потом каким то образом представляется пользователю.
Надоел этот мазохизм. Очень трудомко. Что я должен открыть для себя,
чтобы создание таких приложений было быстрым и продуктивным. Кто как делает.
Повторю требования: Desktop клиент к БД, работа через инет HTTP 80 порт .
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, Аноним, Вы писали:
А>>Повторю требования: Desktop клиент к БД, работа через инет HTTP 80 порт .
AS>1. Remoting + HTTP Binding AS>2. WCF + one from HTTP Binding AS>3. ADO .NET Data Services (не пробовал)
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Здравствуйте, Аноним, Вы писали:
А>>>Повторю требования: Desktop клиент к БД, работа через инет HTTP 80 порт .
AS>>1. Remoting + HTTP Binding AS>>2. WCF + one from HTTP Binding AS>>3. ADO .NET Data Services (не пробовал)
G>2. WCF + one from HTTP Binding + EF
Я не стал EF указывать, потому что можно юзать любой ORM.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>Здравствуйте, Аноним, Вы писали:
А>>>>Повторю требования: Desktop клиент к БД, работа через инет HTTP 80 порт .
AS>>>1. Remoting + HTTP Binding AS>>>2. WCF + one from HTTP Binding AS>>>3. ADO .NET Data Services (не пробовал)
G>>2. WCF + one from HTTP Binding + EF
AS>Я не стал EF указывать, потому что можно юзать любой ORM.
Linq2SQL создает несериализуемые объекты, EF-сущности нормально сереализуются и передаются по WCF каналам.
Здравствуйте, gandjustas, Вы писали:
AS>>Я не стал EF указывать, потому что можно юзать любой ORM. G>Linq2SQL создает несериализуемые объекты, EF-сущности нормально сереализуются и передаются по WCF каналам.
Почему это Linq2SQL создаёт несериализуемые объекты? здесь написано как работать Linq сущностями в службах WCF.
Здравствуйте, gandjustas, Вы писали:
А>>>>>Повторю требования: Desktop клиент к БД, работа через инет HTTP 80 порт .
AS>>>>1. Remoting + HTTP Binding AS>>>>2. WCF + one from HTTP Binding AS>>>>3. ADO .NET Data Services (не пробовал)
G>>>2. WCF + one from HTTP Binding + EF
AS>>Я не стал EF указывать, потому что можно юзать любой ORM.
G>Linq2SQL создает несериализуемые объекты, EF-сущности нормально сереализуются и передаются по WCF каналам.
Здравствуйте, <Аноним>, Вы писали:
А>МУЖИКИ КАК ВЫ ТАКОЕ ДЕЛАЕТЕ
А>Задача:
А>Есть БД. Нужно сделать клиента к ней (Desktop клиент). Клиент должен быть способен А>работать не только в локалке но и в инете. BLToolkit'ом.
На серверной стороне пишу
[OraclePackage("FOOBAR_PACKAGE")]
[GenerateWebService("http://blablabla.org/Services/foo/bar.asmx")]
[GenerateXmlInclude(typeof(FooItem))]
#if DEBUG
[BLToolkit.Aspects.Log]
#endif
public abstract class FooBarPackage: OraclePackageBaseService<FooBarPackage>
{
[GenerateAttribute(typeof(WebMethodAttribute), true)]
public abstract List<FooItem> LoadFoo(string blablablaId);
}
Таким вот макаром оракловые пакеты тупо превращаются в ВебСлужбы.
На клиенте имеем
[GenerateWebServiceBinding("http://blablabla.org/Services/foo/bar.asmx/")]
[GenerateXmlInclude(typeof(FooItem))]
public sealed class FooBarAvatar : WebClientBase<FooBarAvatar>
{
[GenerateSoapDocumentMethod]
public abstract List<FooItem> LoadFoo(string blablablaId);
public abstract void LoadFoo(AsyncCallback<List<FooItem>> callback);
}
Это урл сервиса зашит в код?
Примерно так. Если урл сервиса не задан явно, то берётся имя хоста из .config файла и относительный путь из этого атрибута.
Смешиваются и получается адрес куда клиент и ломится собственно.
Z>2. Как выглядит сам package? С какими типами работает?
Обычный оракловый пакет. Работает со всеми известными науке типами, включая XML и массивы. UDT тоже можно прикрутить — было бы желание.
Здравствуйте, Блудов Павел, Вы писали:
БП>Примерно так. Если урл сервиса не задан явно, то берётся имя хоста из .config файла и относительный путь из этого атрибута. БП>Смешиваются и получается адрес куда клиент и ломится собственно.
т.е. по адресу http://myhost.org/MyServices/foo/bar.asmx приложение уже не разместить без перекомпиляции?
БП>Обычный оракловый пакет. Работает со всеми известными науке типами, включая XML и массивы. UDT тоже можно прикрутить — было бы желание.
И всетаки? Как выглядит процедура/функция возвращающая List<MyItem>?
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Блудов Павел, Вы писали:
БП>>Примерно так. Если урл сервиса не задан явно, то берётся имя хоста из .config файла и относительный путь из этого атрибута. БП>>Смешиваются и получается адрес куда клиент и ломится собственно.
Z>т.е. по адресу http://myhost.org/MyServices/foo/bar.asmx приложение уже не разместить без перекомпиляции?
Почему? Нипишите свою логику для инициализации поля Path (или Url, не помню точно) и будет вам счастье.
У меня есть в одном месте код типа
[GenerateWebServiceBinding("http://blablabla.org/Services/foo/bar.asmx/")]
[GenerateXmlInclude(typeof(FooItem))]
public abstract class FooBarAvatar : WebClientBase<FooBarAvatar>
{
public FooBarAvatar(): base(Settings.Default.FooBarUrl) {}
}
Z>И всетаки? Как выглядит процедура/функция возвращающая List<MyItem>?
Примерно так
CREATE OR REPLACE
FUNCTION LOAD_FOO
RETURN SYS_REFCURSOR
IS
retCursor SYS_REFCURSOR;
BEGIN
OPEN retCursor FOR
SELECT
FOO_ID, FOO_NAME, FOO_BAR
FROM
FOO;
RETURN
retCursor;
END;
/
Т.е. просто возвращаем курсор, а он перекладывается в список или словарь объектов типа Foo.
.
