Веб-сервисы WCF и получение из базы данных - использовать существующий уровень сервиса asp.net? - PullRequest
Новая
       14

Веб-сервисы WCF и получение из базы данных - использовать существующий уровень сервиса asp.net?

1 голос
/ 07 июля 2011

Я только начал работать над проектом служб WCF, используя web.api для предоставления данных для мобильной версии нашего существующего веб-приложения asp.net mvc.

До сих пор я использовал этот WCF web.api учебник по началу работы , чтобы запустить что-то, с поддельными данными, созданными в ServiceContract.

Сервисный контракт выглядит так: 

[WebGet(UriTemplate = "")]
    public IQueryable<Workspace> Get()
    {
        //I want to use our existing service layer like this:
        //WorkspaceService service = new WorkspaceService();
        //service.ReturnAllWorkspacesByUsername("mary");

        //this is fake data for testing
        var workspaces = new List<Workspace>()
        {
            new Workspace() {Id = new Guid(), Title = "Implement WCF Web Services"},
            new Workspace() {Id = new Guid(), Title = "Add APIs to WebService"},
            new Workspace() {Id = new Guid(), Title = "Map Routes"},
            new Workspace() {Id = new Guid(), Title = "Expose Resources"},
        }; 
        return workspaces.AsQueryable();
    }

Я бы хотел как можно больше использовать существующее приложение mvc, как я могу наилучшим образом использовать существующий уровень обслуживания и модель домена или лучше не использовать? Лучше ли разделять услуги?

Кто-нибудь может подсказать мне хорошие уроки для начинающих для этого?

Спасибо, Кай

1 Ответ

0 голосов
/ 07 июля 2011

Я предпочитаю иметь общий уровень бизнес-логики в процессе.DTO (объекты передачи данных) используются для связи между уровнями.Когда уровень доступа к данным основан на EF, я предпочитаю использовать объекты POCO как DTO.Теперь для внешних приложений или другого пользовательского интерфейса я создаю разные сервисные уровни - для получения данных будут использоваться одни и те же BL и DTO.Однако я предпочитаю иметь отдельные классы Data Contract для сервисов.

Логика, лежащая в основе разделения, заключается в том, что API уровня BL может быть более разговорчивым (будучи внутрипроцессным), в то время как API службы будет основан на коренастых взаимодействиях без состояния.Вы можете предоставлять ограниченную функциональность и / или различные API через сервисы (потому что в основе лежит впечатление, что сервисы будут использоваться внешними приложениями).Также рекомендуется разделять DTO и DataContract, так как они могут меняться по-разному и в разное время.Изменения в Контракте данных должны контролироваться и корректироваться, в то время как они могут быть неприменимы к DTO (или объектам домена).

Что касается вашего мобильного пользовательского интерфейса, он не должен использовать сервисы, а напрямую зависит от процессаСлой BL.Это возможно, если ваше оригинальное приложение MVC является многоуровневым.

Еще одно наблюдение - возвращать IQueryable из службы WCF не имеет смысла.Вы можете вернуть массив объектов, и клиентское приложение может привести к IQueryable при необходимости.

...