Как я могу поддерживать дочерние объекты с LinqToSql поверх WCF?

Question

В настоящее время я застрял в разработке этого решения.

Дизайн слоя данных состоит из следующего:

• Рецепт (родительский объект высокого уровня)
  • Сведения о языке (название, описание по языку) (много)
    • Заголовки (много)
    • шагов (много)
      • Ингредиенты (много)
      • Количество (много)
      • Процедуры (много)
    • Примечания (много)

Проблема, с которой я сталкиваюсь, заключается в том, как создать дизайн доступа к данным, который будет добавлять / удалять дочерние объекты в базе данных при заполнении объекта из метода WCF SaveRecipe (recipe)?

Все это вытекает из того, что руководство просит нас добавить коммуникационный уровень в наше приложение, прямо сейчас наш пользовательский интерфейс связан с бизнес-уровнем, а BL напрямую связан с DAL, нам в основном требуется внедрение WCF между BL и DAL.

Я прочитал в этой теме , что использование L2S не является хорошей идеей по сравнению с WCF, но, поскольку дизайн не нов, мы должны использовать этот тип методологии, а затем отойти от как только мы сможем рефакторировать большое количество работы интерфейса.

Answer 1

Если вы пытаетесь отправить материал по линии 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 превращается в кусок пирога.

Answer 2

Я не рекомендую выставлять классы L2S поверх WCF. Создайте иерархию объектов DataContract и передайте их через WCF. Недостатком этого является то, что вам необходимо «глубоко копировать» ваши объекты L2S в иерархию DataContract, но плюс в том, что вы можете включать только те поля, которые необходимы и пригодны для передачи по сети. Например, в проекте, над которым я сейчас работаю, я передаю объект EmployeeData по сети, который включает большинство полей моего сотрудника L2S, но исключает такие вещи, как соленая соль хеша и пароля сотрудника.

Answer 3

Мне нравится этот ответ от Карла в теме , на которую вы ссылались:

Лучше создать свой классы для передачи данных объект. Те классы, конечно же, будет реализован как DataContracts. На вашем сервисном уровне вы бы конвертировали между объектами linq-to-sql и экземпляры объектов носителя данных. Это утомительно, но это разъединяет клиенты сервиса от схема базы данных. Он также имеет Преимущество дает вам лучший контроль данных, которые передаются в ваша система.

Похоже, что вам все равно придется реорганизовать рефакторинг - просто начните с рефакторинга зависимости от linq2sql в вашем уровне пользовательского интерфейса.

Не думаю, что у вас есть быстрое и простое решение.

Answer 4

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

class Recipe {
    [DataMember] public string Name;
    [DataMember] public string Description;
}

class RecipeWithIngredients : Recipe {
    [DataMember] public IList<Ingredient> Ingredients;
}

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