ServiceStack новый сервис бок о бок ASP.NET MVC сайт

В examples для ServiceStack Я не вижу ни одного приложения, которое является веб-сайтом ASP.NET MVC, а затем сделало сервис ServiceStack второй.

Возьмем очень простое веб-приложение ASP.NET MVC, которое отображает продукты через Views. Он использует контроллеры, представления, модели и режимы просмотра.

Скажем, у нас есть модель Product, которая сохраняется в документе DB. Предположим, что у нас есть viewmodel ProductViewModel, который отображается из Product и отображается в MVC Razor View/PartialView.

так что это веб-сторона вещей. Теперь предположим, что мы хотим добавить сервис, возвращающий продукты, для различных клиентов, таких как приложения Windows 8.

Если классы запроса/ответа полностью отключены от того, что у нас уже есть? Наш ProductViewModel может содержать все, что мы хотим вернуть из службы.

Поскольку у нас уже есть Product (класс модели), мы не можем иметь еще один класс Product в пространстве имен API. Ну, мы могли бы, но это делает вещи неясными, и я хотел бы избежать этого.

Итак, следует ли вводить автономный класс ProductRequest и класс ProductRequestResponse (наследует ProductViewModel) в пространстве имен API?

Как и ProductRequestResponse : ProductViewModel?

То, что я говорю, у нас уже есть классы Model и ViewModel, а также для создания классов запроса и ответа для службы SS мы должны были бы создать еще два файла, главным образом путем копирования всего из уже существующих классов. Это не выглядит СУХОЙ для меня, оно может следовать за разделением рекомендаций, но DRY тоже важен, на самом деле больше, чем отделить все (разделение всего приводит к дублированию кода).

То, что я хотел бы увидеть, - это случай, когда веб-приложение уже создано, оно в настоящее время включает модели и ViewModels и возвращает соответствующие представления для отображения в Интернете, но может быть расширено в полностью функциональный сервис для поддержки программных клиентов? Как клиенты AJAX и т.д.... с тем, что у нас уже есть.

Другое дело:

Если вы посмотрите на этот пример https://github.com/ServiceStack/ServiceStack.Examples/blob/master/src/ServiceStack.MovieRest/MovieService.cs

вы увидите, что есть Movie класс запроса и Movies класс запроса (один для одного запроса на фильм, другой для списка фильмов). Таким образом, существуют также две службы MovieService и MoviesService, одна из которых касается запросов к одному фильму, другая - для жанра фильмов.

Теперь, когда мне нравится подход SS к сервисам, и я думаю, что он правильный, мне не нравится такое разделение просто из-за типа запроса. Что, если я хочу кино режиссера? Я бы изобрел еще один класс запроса, имеющий свойство Director и еще одну службу (MoviesByDirector) для него?

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

public class ProductsService : Service
{
    private readonly IDocumentSession _session;
    private readonly ProductsHelperService _productsHelperService;
    private readonly ProductCategorizationHelperService _productCategorization;

    public class ProductRequest : IReturn<ProductRequestResponse>
    {
        public int Id { get; set; }
    }

    // Does this make sense? 
    // Please note, we use ProductViewModel in our Views and it holds everything we'd want in service response also
    public class ProductRequestResponse : ProductViewModel
    {
    }

    public ProductRequestResponse GetProducts(ProductRequest request)
    {
        ProductRequestResponse response = null;
        if (request.Id >= 0)
        {
            var product = _session.Load<Product>(request.Id);
            response.InjectFrom(product);
        }
        return response;
    }
}

Ответ 1

Уровень обслуживания - ваш самый важный контракт

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

DTO - лучшие методы для удаленных служб

Следуя рекомендации Мартина Фаулера по использованию DTO (объекты передачи данных) для удаленных служб (MSDN), ServiceStack поощряет использование чистых, незавершенных POCO для определения четко определенного контракта с ним, который должен храниться в значительной степени без использования и без зависимостей .dll. Преимущества этого позволяют вам повторно использовать типизированные DTO, используемые для определения ваших услуг с помощью, как есть, в С#/.NET клиентах - предоставление сквозной типизированный API без использования каких-либо кодовых или других искусственных машин.

DRY vs Intent

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

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

Он также предоставляет авторитетный источник (который не просочился или не связан внутри вашей логики приложения), который использовался для создания автоматически генерируемых страниц метаданных, пример ответов, поддержка Swagger, XSD, WSDL и т.д.

Использование ServiceStack Встроенное автоматическое сопоставление

Несмотря на то, что мы поддерживаем отдельные модели DTO, вам не нужно поддерживать собственное сопоставление вручную, поскольку вы можете использовать сопоставление, например AutoMapper, или используя встроенный ServiceStack -в Auto Mapping, например:

Создайте новый экземпляр DTO, заполненный соответствующими свойствами в viewModel:

var dto = viewModel.ConvertTo<MyDto>();

Инициализировать DTO и заполнить его соответствующими свойствами в модели представления:

var dto = new MyDto { A = 1, B = 2 }.PopulateWith(viewModel);

Инициализировать DTO и заполнить его с помощью свойств не по умолчанию в модели представления:

var dto = new MyDto { A = 1, B = 2 }.PopulateWithNonDefaultValues(viewModel);

Инициализировать DTO и заполнить его соответствующими свойствами, которые аннотируются с атрибутом Attr в модели представления:

var dto = new MyDto { A=1 }.PopulateFromPropertiesWithAttribute<Attr>(viewModel);

Когда логика преобразования становится более сложной, нам нравится использовать методы расширения, чтобы сохранить код DRY и поддерживать сопоставление в одном месте, которое легко расходуется из вашего приложения, например:

public static class MappingExtensions
{
    public static MyDto ToDto(this MyViewModel viewModel)
    {
        var dto = viewModel.ConvertTo<MyDto>();
        dto.Items = viewModel.Items.ConvertAll(x => x.ToDto());
        dto.CalculatedProperty = Calculate(viewModel.Seed);
        return dto;
    }
}

Что теперь легко расходуется только с помощью:

var dto = viewModel.ToDto();

Ответ 2

Если вы не привязаны специально к ServiceStack и просто хотите "полностью функциональный сервис для поддержки программных клиентов... с тем, что у нас уже есть", вы можете попробовать следующее: вернуть контроллеры либо ViewResult, либо JsonResult на основе заголовка принятия запроса - Request.AcceptTypes.Contains("text/html") или Request.AcceptTypes.Contains("application/json").

Оба ViewResult и JsonResult равны ActionResult, поэтому сигнатура действий остается неизменной, и оба View() и Json() принимают ViewModel. Кроме того, если у вас есть ControllerBase, вы можете сделать базовый метод (например, protected ActionResult RespondWith(Object viewModel)), который вызывает либо View(), либо Json(), поэтому изменение существующего кода минимально.

Конечно, если ваши ViewModels не чисты (т.е. имеют некоторые html-конкретные вещи или вы полагаетесь на некоторые магии ViewBag), то это немного больше работы. И вы не получите SOAP или другие типы привязок, предоставляемые ServiceStack, но если ваша цель - поддерживать интерфейс данных JSON с минимальными изменениями кода в существующем приложении MVC, то это может быть решением.

Лп