Question

我很好奇为什么决定将ServiceStack中的Service基类与数据访问（通过Db属性）相结合？对于Web服务，使用Data Repository模式从数据库中获取原始数据非常流行。许多服务都可以使用这些数据存储库，而无需调用服务类。

例如，假设我支持在全国范围内运营的大型零售连锁店。有许多设置会因税率等所有商店而异。每次调用其中一个Web服务都需要域逻辑的这些设置。在存储库模式中，我只需创建一个数据访问类，其唯一的责任是返回这些设置。但是在ServiceStack中，我将这些设置作为服务公开（它也需要它）。在我的服务电话中，我最终做的第一件事是新建设置服务并在我的其他服务中使用它。这是意图吗？由于服务返回一个对象，我必须将结果转换为类型化的服务结果。

Answer 1

ServiceStack便利性ADO.NET IDbConnection Db属性允许您快速创建数据库驱动的服务（即最流行的类型），而无需创建存储库（如果需要）的开销和样板。由于ServiceStack服务已经可以测试，并且DTO模式提供了一个干净的端点无关的Web服务接口，因此将“一次性”数据访问包装和代理到单独的存储库中通常没有太多价值。

但与此同时，没有任何东西强迫你使用base.Db属性，（如果未使用则无效）。 Unit Testing Example on the wiki显示了使用base.Db或存储库模式的示例：

public class SimpleService : Service
{
   public IRockstarRepository RockstarRepository { get; set; }

   public List<Rockstar> Get(FindRockstars request)
   {
      return request.Aged.HasValue
          ? Db.Select<Rockstar>(q => q.Age == request.Aged.Value)
          : Db.Select<Rockstar>();
   }

   public RockstarStatus Get(GetStatus request)
   {
      var rockstar = RockstarRepository.GetByLastName(request.LastName);
      if (rockstar == null)
          throw HttpError.NotFound("'{0}' is no Rockstar".Fmt(request.LastName));

      var status = new RockstarStatus
      {
          Alive = RockstarRepository.IsAlive(request.LastName)
      }.PopulateWith(rockstar); //Populates with matching fields

      return status;
   }
}

注意：返回object或类型为RockstarStatus的强类型DTO响应在ServiceStack中具有相同的效果，因此如果愿意，您可以返回强类型响应并避免任何转换。

为什么数据访问与ServiceStack中的服务基础紧密耦合

1 个答案: