2015-02-23 3 views
0

Я создаю задний конец EntityFramework/WebApi.
Я хочу отделить мой WebApi от Entity Framework и использовать Injection Dependency, чтобы я мог поменять «источник данных» для веб-API. Я смотрел образцы модели работы и хранилища.Использование инъекции зависимостей с Breezejs

Я также хочу использовать breezejs.

образцов breezejs TempHire было много помощи, так что я буду использовать это в качестве примера для моего вопроса -

https://github.com/Breeze/breeze.js.samples/tree/master/net/TempHire

В этом примере на стороне данных у нас есть класс UnitOfWork -

public class UnitOfWork 
{ 
    private readonly EFContextProvider<TempHireDbContext> _contextProvider; 

    public UnitOfWork() 
    { 
     _contextProvider = new EFContextProvider<TempHireDbContext>(); 

     StaffingResources = new Repository<StaffingResource>(_contextProvider.Context); 
     Addresses = new Repository<Address>(_contextProvider.Context); 
     // .. etc. 
    } 

    public IRepository<StaffingResource> StaffingResources { get; private set; } 
    public IRepository<Address> Addresses { get; private set; } 
    // .. etc. 

    public SaveResult Commit(JObject changeSet) 
    { 
     return _contextProvider.SaveChanges(changeSet); 
    } 
} 

Тогда на стороне WebAPI, он использует его, как это -

[BreezeController] 
[Authorize] 
public class ResourceMgtController : ApiController 
{ 
    private readonly UnitOfWork _unitOfWork = new UnitOfWork(); 

    [HttpPost] 
    public SaveResult SaveChanges(JObject saveBundle) 
    { 
     return _unitOfWork.Commit(saveBundle); 
    } 
    // ... etc. 
} 

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

public class UnitOfWork : IUnitOfWork 

public class ResourceMgtController : ApiController 
{ 
    private readonly IUnitOfWork _unitOfWork; 
    public ResourceMgtController(IUnitOfWork unitOfWork) { 
     this._unitOfWOrk = unitOfWork; // Dependency Injected... 
    }  
    // ... etc. 
} 

То, что я не могу обвести вокруг себя, - это то, как я могу сделать это родовым. Клиент ветер нужен метод, как это -

[HttpPost] 
public SaveResult SaveChanges(JObject saveBundle) 
{ 
    return _unitOfWork.Commit(saveBundle); 
} 

И я не могу поставить это в IUnitOfWork -

SaveResult SaveChanges(JObject saveBundle) 

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

ответ

1

Вы можете четко определить интерфейс с этим методом:

public interface IUnitOfWork { 
    ... 
    SaveResult SaveChanges(JObject saveBundle); // no problem 
} 

Я подозреваю, что вы возражая на то, что оба SaveResult и JObject являются классы, определенные библиотеки (Breeze.ContextProvider и Newtonsoft.Json.Linq соответственно) вы бы скорее не упоминается где-то.

Эти ссылки не беспокоят меня больше, чем я имею в виду, ссылаясь на System.Linq, чтобы получить IQueryable. Фактически, тестовый двойник SaveResult (открытый класс Breeze.ContextProvider) тривиально прост в построении. Вот его определение (и определение KeyMapping, его только неродного зависимый тип):

public class SaveResult 
{ 
    public List<object> Entities; 
    public List<KeyMapping> KeyMappings; 
    public List<object> Errors; 
} 

public class KeyMapping 
{ 
    public string EntityTypeName; 
    public object TempValue; 
    public object RealValue; 
} 

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

public interface IUnitOfWork { 
    ... 
    object SaveChanges(object saveBundle); // no safety, no problem 
    } 

Затем в бетоне UnitOfWork вы добавите подходящую перегрузку:

public object IUnitOfWork.SaveChanges(object saveBundle) 
{ 
    return SaveChanges((JObject) saveBundle); 
} 

public SaveResult SaveChanges(JObject saveBundle) 
{ 
    return _contextProvider.SaveChanges(saveBundle); 
} 

...и Боб - твой дядя.

Да, я попробовал (в DocCode); отлично работал для меня.

+0

С уважением, Уорд. Ваше решение - это то, что я сделал! Вы точно читали мое сообщение - я возражал, что я как бы добавляю специальный код бриза в свой общий интерфейс - особенно с необходимостью добавить метод для возврата метаданных, о котором я не упоминал. Если бы я захотел поменять его на прямое решение без кэша WebApi/EF, savechanges могли бы выглядеть более как это - public void SaveChanges() {\t _ctx.SaveChanges(); }, и метаданные будут неактуальны. Поэтому я предполагаю, что мой интерфейс UnitOfWork должен быть совместим с breeze независимо от хранилища данных. – user210757

Смежные вопросы