Уровень данных C # и Dto's

Question

Я недавно присоединился к компании, которая использует типизированные наборы данных в качестве «Dto». Я думаю, что они действительно мусор и хотят изменить его на что-то более современное и удобное для пользователя. Итак, я пытаюсь обновить код, чтобы уровень данных был более общим, то есть с использованием интерфейсов и т. Д., Другой парень не знает, что такое Dto, и у нас возникли небольшие разногласия относительно того, как это должно быть сделано.

Не пытаясь склонить людей к моему мышлению, я хотел бы получить от вас, люди, беспристрастные ответы о том, в каких слоях может присутствовать Dto. Все слои; DAL, BL и Presentation или небольшой поднабор только в этих слоях.

Кроме того, объекты IList должны или не должны присутствовать в DAL.

Спасибо.

Answer 1

Это действительно зависит от вашей архитектуры.

В большинстве случаев вы должны пытаться кодировать интерфейсы, тогда не имеет значения, какова ваша реализация.Если вы возвращаете ISomething, это может быть ваш SomethingEntity или SomethingDTO, но ваш потребляющий код не заботится, пока он реализует интерфейс.

Вы должны возвращать IList / ICollection / IEnumerable по конкретной коллекции илимассив.

• Свойства не должны возвращать массивы
• Не предоставлять общие списки

Что выследует сначала попытаться отделить ваш код и сделать его слабосвязанным, вставив некоторые интерфейсы между вашими уровнями, такие как хранилище для вашего уровня DataAccess.Затем ваш репозиторий возвращает ваши объекты, инкапсулированные интерфейсом.Это сделает ваш код более тестируемым и позволит вам легче имитировать.После того, как вы подготовите свои тесты, вы сможете изменить реализацию с меньшим риском.

Если вы начнете использовать интерфейсы, я бы предложил скорее интегрировать IoC, такой как Windsor, чем позже.Если вы сделаете это с самого начала, это облегчит вашу жизнь.

Answer 2

Одна вещь состоит в том, что DataSets не способны обеспечить совместимость.Даже типизированные наборы данных также не очень совместимы, когда речь идет о потреблении типизированных наборов данных от не .net-клиента.Ссылка на эту ссылку .Если вам нужно добиться совместимости, тогда боритесь за DTO, в противном случае постарайтесь, чтобы ваша команда понимала DTO в течение определенного периода времени, потому что наборы данных все же не так уж и плохи.,Например - если вы возвращаете List<T> из DAL, вместо этого вы должны вернуть IList<T>.Некоторые люди доходят до IEnumerable<T>, потому что все, что вам нужно, - это способность перечислять.Но тогда, делая это, не становитесь архитектором астронавтов .

. В моих приложениях я выяснил, что возвращение IList<T> вместо List<T> загрязняет мою кодовую базу с помощью таких кодов:

//consider personCollection as IList<Person>
(personCollection as List<Person>).ForEach(//Do Something)

Поэтому я лично стараюсь поддерживать баланс между возвращающимся интерфейсом или конкретным объектом.Если вы спросите меня, что я делаю сейчас, я скажу, что возвращаюсь List<T>.На меня повлияло то, что я не стал архитектором-космонавтом .

Answer 3

По определению DTO - это объект передачи данных, используемый для (ожидания его) передачи данных с одного уровня на другой.

DTO могут использоваться на всех уровнях, и я хорошо использовал их с веб-сервисами.

Answer 4

Я всегда использую DTO, а не DataTable.Но я использую их только для перевода из BL в DL и наоборот.Мои уровни представления часто осведомлены о бизнес-уровне и уровне обслуживания только в случае ориентированного на обслуживание.

Преимущества, которые я вижу в использовании DTO, а не в виде данных:

• простой рефакторинг
• создание простых диаграмм
• более понятный код, особенно в модульных тестах DAL