Nano Hash - криптовалюты, майнинг, программирование

Включает параметры универсального типа

Я пишу некоторый код BLL, чтобы сидеть поверх инфраструктуры Entity (классы DAL, созданные с помощью DBContext, но это не имеет значения для этого вопроса). Вот одна из моих процедур:

public static Customer Get(int32 CustID, IEnumerable<string> IncludeEntities = null)
{
}

Поэтому, когда я вызываю его, я передаю CustID, необязательный список объектов, которые я хочу включить, например «Заказы» и «Детали заказа»:

Customer customer = CustomerBLLRepository.Get("ALFKI", 
     new[] { "Orders", "Orders.Order_Details"});

Он работает нормально, но мне не нравится вызывать его со списком или массивом строк — я хотел бы получить строгую типизацию, чтобы IDE могла помочь.

Я мог бы получить список типов, объявив его так:

public static void GetTest(Int32 CustID, params Type[] IncludeEntities)
{
}

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

CustomerRepository.GetTest(123, typeof(Order), typeof(OrderDetails));

что не является концом света, но это вызывает проблемы, потому что OrderDetails на самом деле является навигационным свойством из Orders, а включение должно называться Orders.OrderDetails, и мне пришлось бы искать код, чтобы найти, какая сущность OrderDetails в дочернем элементе и по-прежнему генерировать строку.

Что мне действительно нужно, так это строго типизированный список сущностей для передачи в качестве включений в том же формате, который EF хочет, чтобы они включались, но я думаю, что я SOL.


  • Было бы сложно попросить сделать это по типам. Что, если у клиента есть два свойства, соответствующие типу заказа? например, Customer.OpenOrders и Customer.CompletedOrders, оба типа List‹Order›. 17.12.2012
  • Вы можете использовать перечисление. Таким образом, вы можете управлять списком значений. Непосредственное использование типов может поставить вас в положение, когда кто-то вводит тип, который даже не является сущностью. Это может привести к некоторым сложным сценариям проверки аргументов. 17.12.2012
  • Мэтт, я пропустил тот факт, что теперь вы можете использовать лямбду с включением, так что это очевидный ответ, я думаю. 17.12.2012
  • Однако не спутайте этот метод с тем, который относится к BLL! 17.12.2012

Ответы:


1

Предполагая, что в вашей модели EF поддерживаются отношения, почему бы не использовать пользовательскую процедуру получения, которая принимает Lambda. На основе вашего образца вы получаете «клиента».

public class RepositoryCustomer: RepositoryBase<Customer> 
...
...
public class RepositoryEntityBase<T>
   public virtual T Get(Expression<Func<T, bool>> predicate)
       return Context.Set<T>.Where(predicate).FirstOrDefault();

Вы вызываете процедуру Generic Get для любых наборов в вашем контексте,

var aCustomer = RepositoryCustomer.Get(c=>c.id=="ALFKI" && c.Orders.OrderDetail=="bla")

Свойства виртуальной навигации очень полезны и гибки.

17.12.2012
  • Привет, спасибо за комментарий. Я понимаю, о чем вы говорите, и у меня есть такие подпрограммы, но я думаю, что проблема в том, что я хочу отключить ленивую загрузку, поэтому я должен явно перечислить включаемые объекты, нет? Я хочу учиться... спасибо, Рэй. 17.12.2012
  • Context.Configuration.LazyLoadingEnabled = true; // ложный ? если вы хотите узнать больше о нетерпеливой загрузке... stackoverflow.com/questions/6042023/ 17.12.2012
  • Привет, спасибо за это. Я знаю, как отключить ленивую загрузку - чего мне не хватает, так это того, как ваш ответ помогает со списком включений. Если ленивая загрузка отключена, я понимаю, что я обязан перечислить нужные включения. Я не хочу перечислять их как строки, и, как я прокомментировал выше, я понял, что могу использовать лямбда - предлагает ли ваше предложение что-то, что мне не хватает? Спасибо Рэй 17.12.2012
  • Думаю, нет, извините. Если вам все это возможно с .Where.Select(new .Where...) 18.12.2012

  • 2

    Определение объектов, которые следует включить в запрос, не должно быть задачей ни для кого, кроме BLL. Если BLL принимает свойство или несколько свойств, которые относятся к структуре хранилища данных, то вы говорите, что любые вызовы BLL должны знать о внутренней структуре хранилища данных. Изменить: недостаточно ясно. Это просто неправильно.

    IMO, вы должны создать отдельный метод для каждого варианта использования, иначе ваш BLL будет просто вспомогательным методом для DAL и не несет ответственности за разделение задач.

    Это серьезная проблема с Entity Framework - MS создает впечатление, что вы должны объединять свои запросы в любой момент, когда вам нравится, а также использовать и поддерживать сущности в любом месте. Действительно очень трудно увидеть свет.

    17.12.2012
  • Кирен, Возьмем пример. Некоторым клиентам этого BLL может просто понадобиться клиент. Другим может понадобиться клиент и заказы. И т. д. Вы предлагаете отдельный метод для каждого из них? Например, в реальном мире и в модели, с которой я работаю, у меня более 30 связанных объектов. Я думаю, что отдельный метод для каждой комбинации сущностей был бы подавляющим. Я готов выслушать альтернативные аргументы. Лучший Рэй 17.12.2012
  • Думайте о BLL как о выполнении контракта. Контакт не стоит иметь, если вы проходите всю стратегию - в ее нынешнем виде вы смотрите на GetStuff(). Это не контракт, это откладывает любой хороший дизайн и мысль до более позднего момента (когда вы вызываете метод). Если у вас есть 30 различных вариантов использования/историй/способов, которые необходимы вашему приложению для получения информации о клиентах, вам нужны разные методы. Я предлагаю: не делайте BLL универсальным, имейте методы для каждой из требуемых работ/задач. Представьте, что BLL — это максимально конкретный API для написания внешнего интерфейса. 17.12.2012
  • Кирен, я понимаю вашу точку зрения - и BLL не является общим, а только его частью. Материал CRUD является общим, и я сопоставляю объекты домена и объекты DAL. Частичный класс позволяет мне писать валидацию и добавлять пользовательские методы, но операции CRUD одинаковы для всех объектов, и я не занимаюсь ручным кодированием всех этих методов. Был там раньше, и это PITA, когда структура меняется. Я автоматически генерирую базовые классы BLL с автоматическим CRUD и сопоставлением с шаблоном T4. Лучший Рэй 17.12.2012
  • Новые материалы

    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..