Как я могу поддерживать дочерние объекты с помощью LinqToSql поверх WCF?
-
03-07-2019 - |
Вопрос
В настоящее время я застрял в разработке этого решения.
Структура уровня данных состоит из следующего:
- Рецепт (родительский объект высокого уровня)
- Подробности о языке (название, описание по языку) (много)
- Заголовки (много)
- Шаги (много)
- Ингредиенты (много)
- Количества (много)
- Процедуры (много)
- Примечания (много)
- Подробности о языке (название, описание по языку) (много)
Проблема, с которой я сталкиваюсь, заключается в том, как создать структуру доступа к данным, которая будет добавлять/удалять дочерние объекты в базе данных, когда объект заполняется из метода WCF SaveRecipe(recipe)?
Все это связано с тем, что руководство просит нас добавить уровень связи в наше приложение, прямо сейчас наш пользовательский интерфейс связан с нашим бизнес-уровнем, а BL напрямую связан с DAL, нам в основном нужна инъекция WCF между BL и DAL. .
я прочитал в эта тема что использование L2S не является хорошей идеей по сравнению с WCF, но, поскольку конструкция не нова, нам придется использовать этот тип методологии, а затем отойти от нее, как только мы сможем провести рефакторинг большого объема работы с пользовательским интерфейсом.
Решение
Если вы пытаетесь отправить что-то по линии с помощью WCF, я предлагаю вам создать модель данных, которые вы хотите перемещать по своему домену.Насколько я обнаружил, вы не можете сериализовать объекты IQueryable, но вы можете создать набор классов, которые заполняет Linq, а затем сериализовать его.Например:
[DataContract]
public class Recipe {
[DataMember]
public string Name { get; set; }
[DataMember]
public string Description { get; set; }
[DataMember]
public List<Ingredient> Ingredients { get; set; }
}
Затем заполните это
List<Recipe> recipes = (from r in dc.recipe
select new Recpie {
Name = r.name,
Description = r.description,
Ingredients = (Linq code to make list of ingredients)
}).ToList();
А затем отправка списка с помощью WCF становится проще простого.
Другие советы
Мне нравится этот ответ от Карла на нить вы ссылались:
Лучше создать свои собственные классы для передачи объекта данных.Эти классы, конечно, будут реализованы как обработки данных.В вашем сервисном уровне вы преобразуете между объектами LINQ-SQL и экземплярами объектов носителя данных.Это утомительно, но он освобождает клиентов Сервиса из схемы базы данных.Он также имеет то преимущество, что дает вам лучший контроль над данными, которые передаются в вашей системе.
Похоже, вам в любом случае придется провести рефакторинг — так же хорошо начать с рефакторинга зависимости от linq2sql на вашем уровне пользовательского интерфейса.
Я не думаю, что у вас есть быстрое и простое решение.
Я не рекомендую предоставлять доступ к классам L2S через WCF.Создайте иерархию объектов DataContract и передайте ее через WCF.Обратной стороной этого является то, что вам придется «глубоко копировать» объекты L2S в иерархию DataContract, но положительным моментом является то, что вы можете включать только те поля, которые необходимы и подходят для передачи по сети.Например, в проекте, над которым я сейчас работаю, я передаю по сети объект «СотрудникData», который включает в себя большинство моих полей «Сотрудник» L2S, но исключает такие вещи, как «соленый» хеш и пароль сотрудника.
Также может быть идея создать классы, включающие и исключающие дочерние записи.Иногда я создавал такие классы:
class Recipe {
[DataMember] public string Name;
[DataMember] public string Description;
}
class RecipeWithIngredients : Recipe {
[DataMember] public IList<Ingredient> Ingredients;
}
Редактировать:случайно опубликовано до того, как сообщение было закончено.