Я использую Linq-To-SQL для проекта с 75 таблицами. Мы должны хранить кэш целых таблиц, которые мы храним, потому что все сущности взаимосвязаны, и их извлечение по требованию занимает слишком много времени. Итак, чтобы отслеживать все эти объекты из всех этих таблиц, у нас есть один класс, отвечающий за поддержание ссылок на таблицы в памяти. Этот объект Cache имеет различное свойство для каждой из 75 ссылок на таблицы, и каждая ссылка кэширует свою таблицу по требованию. например:
private EntityTableReference _reference;
public EntityTableReference EntityTableReference
{
get
{
// Caches all entities from the table
return _reference ?? (_reference = new EntityTableReference(this));
}
}
Так вот, я видел много гидов, говорящих, что это действительно противоречит принципам ОО. Объект Cache ничего не делает , он просто предоставляет общий объект для передачи, так что мы можем отправлять одну ссылку на объект Cache в наших вызовах функций, а не ссылку на каждую таблицу, которую функция нужен доступ. Это очень хорошо работает для нас, и я не вижу никаких недостатков с точки зрения удобства обслуживания, читаемости, скорости и т. Д.
Есть ли критика такого рода проектного решения? Это тот случай, когда нарушать правила можно, потому что мы оценили преимущества и недостатки, или я что-то упустил здесь и закопался в яму?