Все мы ищем тот же IRepository?

ngOnInit не сработает, если вы вернетесь на страницу после помещения ее в стопку ...

Вы можете использовать один из следующих хуков жизненного цикла:

ionViewWillEnter - срабатывает при входе на страницу (также если она возвращается из стека)

ionViewDidEnter - срабатывает после входа ( также, если он вернулся из стека)

11
задан thinkbeforecoding 11 February 2009 в 13:02
поделиться

3 ответа

  1. Первый подход выполним, я сделал что-то подобное в прошлом, когда я записал свою собственную платформу отображения, которая предназначалась для RDBMS и XmlWriter/XmlReader. Можно использовать этот вид подхода для упрощения поблочного тестирования, хотя я думаю теперь, что у нас есть превосходящие инструменты OSS для того, чтобы сделать просто это.

  2. Второй подход - то, что я в настоящее время использую теперь с картопостроителями IBATIS.NET. Каждый картопостроитель имеет интерфейс, и каждый картопостроитель [мог] обеспечить Ваши основные операции CRUD. Преимуществом является каждый картопостроитель для доменного класса, также имеет определенные функции (такой как SelectByLastName или DeleteFromParent) это выражается интерфейсом и определяется в конкретном картопостроителе. Из-за этого нет никакой потребности во мне реализовать отдельные репозитории, как Вы предполагаете - наши конкретные картопостроители предназначаются для базы данных. Для выполнения модульных тестов, я использую StructureMap и Moq для создания репозиториев в оперативной памяти, которые действуют в качестве Вашего Memory*Repository делает. Его меньше классов, чтобы реализовать и справиться и меньше работы в целом для очень тестируемого подхода. Для данных, совместно использованных через модульные тесты, я использую шаблон разработчика для каждого доменного класса, который имеет WithXXX методы и AsSomeProfile методы ( AsSomeProfile просто возвращает экземпляр разработчика с предварительно сконфигурированными данными тестирования).

Вот пример того, с чем я обычно заканчиваю в своих модульных тестах:

// Moq mocking the concrete PersonMapper through the IPersonMapper interface
var personMock = new Mock<IPersonMapper>(MockBehavior.Strict);
personMock.Expect(pm => pm.Select(It.IsAny<int>())).Returns(
    new PersonBuilder().AsMike().Build()
);

// StructureMap's ObjectFactory
ObjectFactory.Inject(personMock.Object);

// now anywhere in my actual code where an IPersonMapper instance is requested from
// ObjectFactory, Moq will satisfy the requirement and return a Person instance
// set with the PersonBuilder's Mike profile unit test data
5
ответ дан 3 December 2019 в 09:42
поделиться

На самом деле существует общее согласие теперь, когда Доменные репозитории не должны быть универсальными. Ваш репозиторий должен выразить то, что можно сделать при сохранении или получении объектов.

Некоторые репозитории только для чтения, некоторые - вставка только (никакое обновление, нет удалите), у некоторых есть только определенные поиски...

Используя IQueryable возврата GetAll, Ваша логика запроса просочится в Ваш код, возможно к прикладному уровню.

Но все еще интересно использовать вид интерфейса, который Вы обеспечиваете для инкапсуляции Linq Table<T> объекты так, чтобы можно было заменить его в реализации памяти для тестовой цели.

Таким образом, я предлагаю, для вызова его ITable<T>, дайте ему тот же интерфейс что linq Table<T> объект и использование это в Ваших определенных доменных репозиториях (не вместо).

Можно затем использовать Вас определенные репозитории в памяти при помощи в памяти ITable<T> реализация.

Самый простой способ реализовать ITable<T> в памяти должен использовать a List<T> и получите a IQueryable<T> интерфейс с помощью.AsQueryable () дополнительный метод.

public class InMemoryTable<T> : ITable<T>
{
    private List<T> list;
    private IQueryable<T> queryable;

   public InMemoryTable<T>(List<T> list)
   { 
      this.list = list;
      this.queryable = list.AsQueryable();
   }

   public void Add(T entity) { list.Add(entity); }
   public void Remove(T entity) { list.Remove(entity); }

   public IEnumerator<T> GetEnumerator() { return list.GetEnumerator(); }

   public Type ElementType { get { return queryable.ElementType; } }
   public IQueryProvider Provider {     get { return queryable.Provider; } }
   ...
}

Можно работать в изоляции базы данных для тестирования, но с истинными определенными репозиториями, которые дают более доменное понимание.

4
ответ дан 3 December 2019 в 09:42
поделиться

Это немного поздно ... но взгляните на реализацию IRepository на CommonLibrary.NET на codeplex. У него довольно хороший набор функций.

Что касается вашей проблемы, я вижу, что многие люди используют такие методы, как GetAllProducts (), GetAllEmployees () в своей реализации репозитория. Это избыточно и не позволяет вашему репозиторию быть универсальным. Все, что вам нужно, это GetAll () или All (). Приведенное выше решение действительно решает проблему именования.

Это взято из документации CommonLibrary.NET в Интернете:

0.9.4 Beta 2 имеет мощную реализацию репозитория.

* Supports all CRUD methods ( Create, Retrieve, Update, Delete )
* Supports aggregate methods Min, Max, Sum, Avg, Count
* Supports Find methods using ICriteria<T>
* Supports Distinct, and GroupBy
* Supports interface IRepository<T> so you can use an In-Memory table for unit-testing
* Supports versioning of your entities
* Supports paging, eg. Get(page, pageSize)
* Supports audit fields ( CreateUser, CreatedDate, UpdateDate etc )
* Supports the use of Mapper<T> so you can map any table record to some entity
* Supports creating entities only if it isn't there already, by checking for field values.
2
ответ дан 3 December 2019 в 09:42
поделиться
Другие вопросы по тегам:

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