Вопросы Теги

ПРИЗМА и WCF - они играют по правилам?

Представление в Oracle и в других системах баз данных является просто представлением SQL-оператора, который хранится в памяти так, чтобы это могло легко быть снова использовано. Например, если мы часто выходим, следующий запрос 

SELECT customerid, customername FROM customers WHERE countryid='US';

Для создания представления используют команда CREATE VIEW, как замечено в этом примере 

CREATE VIEW view_uscustomers
AS
SELECT customerid, customername FROM customers WHERE countryid='US';

, Эта команда создает новое представление, названное view_uscustomers. Обратите внимание, что эта команда не приводит ни к чему на самом деле сохраненному в базе данных вообще за исключением словарной статьи данных, которая определяет это представление. Это означает каждый раз запросы этого представления Oracle должна выйти и выполнить представление и запросить данные базы данных. Мы можем запросить представление как это: 

SELECT * FROM view_uscustomers WHERE customerid BETWEEN 100 AND 200;

И Oracle преобразует запрос в это: 

SELECT * 
FROM (select customerid, customername from customers WHERE countryid='US') 
WHERE customerid BETWEEN 100 AND 200

Преимущества использования Представлений

  • Общность используемого кода. Так как представление основано на одном едином наборе SQL, это означает это, когда это называют it’s менее вероятно для требования парсинга.
  • безопасность. Представления долго использовались для сокрытия таблиц, которые на самом деле содержат данные, которые Вы запрашиваете. Кроме того, представления могут использоваться для ограничения столбцов, к которым у данного пользователя есть доступ.
  • Предикат, продвигая

можно найти усовершенствованные темы в этой статье о" , Как Создать и Справиться с Представлениями в Oracle. "

15
задан Spooky 20 June 2015 в 18:26
поделиться

2 ответа

Это кажется сложным подходом к проблеме.

Вы вызываете событие из клиентского приложения или вызываете события из службы с помощью контракта обратного вызова? или оба?

Я бы подошел к этому с помощью простого класса обслуживания в клиенте. Он может реализовать контракт обратного вызова, и для каждого метода обратного вызова он может просто вызвать событие Prism локально для любых подписчиков в клиенте. Если вам нужно инициировать события, которые обрабатываются службой, тогда класс службы может подписаться на эти события и вызвать службу wcf.

Все, что вам действительно нужно, это класс, который абстрагирует детали службы wcf от клиента. , и предоставляет интерфейс через события Prism.

Лично я бы не стал '

0
ответ дан 1 December 2019 в 05:19
поделиться

Это очень интересный подход. Я бы сказал здесь только две вещи:

  1. Вы действительно напрашиваетесь на проблемы, если используете строки и параметры объекта . Здесь можно использовать строго типизированные события EventAggregator (унаследованные от CompositeEvent). Если вы это сделаете, ремонтопригодность значительно возрастет.
  2. Ваша модель для WCF -> EventAggregator должна рассматривать все , отправляемые и исходящие от EventAggregator, как «событие», а все, поступающее в / из служб WCF, как «сообщения» . Что вы действительно должны учитывать, так это то, что вы, по сути, преобразуете событие EventAggregator в сообщение, а не задаете вопрос «как мне вызвать события WCF».

Я думаю, что вы делаете это возможно. Глядя на вашу реализацию, мне действительно нравится, как вы об этом думаете.

Небольшая альтернатива (со строгим набором текста)

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

Рассматривали ли вы возможность реализации интерфейса службы на основе EventAggregator? Допустим, в вашем примере у вас есть служба WCF IWeatherService, с которой вы работаете. В настоящее время, насколько я понимаю, ваше использование будет выглядеть примерно так:

  1. Клиент использует клиентскую библиотеку событий WCF и вызывает RaiseEvent ("ChangeWeather", Weather.Sunny);
  2. Клиентская библиотека событий WCF переводит это в соответствующий вызов службы WCF, ожидающей получения этого сообщения, используя для этого интерфейс канала IWeatherService. Вероятно, с большим неприятным оператором switch, основанным на имени вызова метода.

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

Напишите поддерживаемую EventAggregator реализацию IWeatherService, которая генерирует события для получения центральным брокером сообщений и передает эту реализацию в вашем контейнере для клиентов. 

public ClientWeatherService : IWeatherService
{

    IEventAggregator _aggregator;
    public ClientWeatherService(IEventAggregator aggregator) 
    { 
        _aggregator = aggregator; 
    }

    public void ChangeWeather(Weather weather)
    {
        ChangeWeatherEvent cwEvent = _aggregator.GetEvent<ChangeWeatherEvent>();
        cwEvent.Publish(weather);
    }
}

Оттуда, вместо того, чтобы использовать вашу «клиентскую библиотеку событий WCF» напрямую, они напрямую используют IWeatherService, не зная, что он не вызывает фактическую службу. 

public MyWeatherViewModel : ViewModel
{
    IWeatherService _weatherService;
    public MyWeatherViewModel(IWeatherService weatherService)
    {
        _weatherService = weatherService;
    }
}

Затем вы Мне нужно было настроить обработчик событий для выполнения вызовов WCF к реальной службе, но теперь у вас есть преимущество строгой типизации от клиентов.

Просто мысль.

Мне очень нравятся вопросы такого типа. Я бы хотел, чтобы больше людей задавали такие вопросы в Stackoverflow. Заставляет мозг двигаться по утрам:

5
ответ дан 1 December 2019 в 05:19
поделиться
Другие вопросы по тегам:

Похожие вопросы: