Здравствуйте, gandjustas, Вы писали:
G>Приведи пример такого кода.
G>Для начала простой кейс как в StackOverflow:
G>1) Показывать посты по дате добавления
G>2) Показывать посты по количеству оценок за день (самые популярные)
G>3) Показывать посты по комментов за день (самые обсуждаемые)
G>Еще обязательно пейджинг.
G>Я предполагаю что получится такой набор методов в репозитариях:
G>G>IEnumerable<PostData> GetPostsByDate(int start, int pageSize);
G>IEnumerable<PostData> GetPostsByComments(int start, int pageSize);
G>IEnumerable<PostData> GetPostsByScore(int start, int pageSize);
G>
Я в репозиторий передаю наследников такого класса:
| | DataFetch.cs |
| | public class DataFetch
{
public static readonly int[] AvailablePageSizes = new[] { 10, 20, 50, 100 };
private int? pageSize;
public DataFetch()
{
this.PageSize = NormalizePageSize(null);
}
public bool? Ascending { get; set; }
public int Page { get; set; }
public int? PageSize
{
get
{
return this.pageSize;
}
set
{
this.pageSize = NormalizePageSize(value);
}
}
public bool? Reset { get; set; }
public string SortBy { get; set; }
private static int NormalizePageSize(int? pageSize)
{
if (pageSize == null)
return AvailablePageSizes.Min();
return AvailablePageSizes.Aggregate((x, y) => Math.Abs(x - pageSize.Value) < Math.Abs(y - pageSize.Value) ? x : y);
}
}
|
| | |
G>Потом внезапно требуется сделать фильтр по тегам, придется править все три метода. В итоге у нас "нижние" слои приложения страдают от изменений деталей представления. Значит расслоение сделано неверно.
G>В сценарии интернет-магазина или CRM может быть куча фильтров и сортировок и таких методов в репозитарии будет очень много. Поэтому цена изменения станет огромной.
При изменении требований я добавляю поля в наследника (PostFetch) и изменяю реализацию метода GetPosts в репозитории (в единственном экземпляре).
IEnumerable<PostDetails> GetPosts(PostFetch fetch)
