Архитектурный вопрос для уровня .Net Development

Привет всем, я довольно новичок в многоуровневом процессе разработки. В настоящее время я разрабатываю приложение, и у меня есть некоторые основные вопросы, касающиеся лучших практик/архитектурных вопросов с сегодняшней технологией. Я буду использовать WCF в качестве уровня сервиса. Заметьте, я стараюсь как можно больше разделить вещи. Я не хочу, чтобы в верхних ярусах ничего не было, чтобы знать о чем-либо в нижнем ярусе, что является одной из причин, по которым мне не нравится LINQ TO SQL или инфраструктура сущности.

1) Каков наилучший способ передачи данных между уровнями? Я знаю, что набор данных или данные будут легкими, но я бы не подумал, что передача этой раздутой структуры данных между уровнями будет лучшим решением. Кроме того, отладка будет сложнее, если данные datasables/datasets будут большими. Может быть, массив объектов POCO будет лучшим решением или есть лучший способ?

2) Следующий вопрос немного сложнее. Множество приложений будет иметь множество разных представлений данных. У вас может быть несколько отчетов, множество данных, а может быть, диаграмма или два. Как вы собираетесь разрабатывать свой уровень данных для этого? Вы просто создаете функцию типа "Get" для каждой таблицы, а затем попытаетесь объединить их в полезные представления, например, сетку или отчет на уровне вашего бизнеса, или у вас есть специализированная функция для каждого вида, который вам нужен на уровне бизнеса.

Честно говоря, мне не нравится какое-либо решение. Если вы выбираете специализированную логику для каждого представления, вам нужно будет создать объект POCO (при условии, что вы собираетесь возвращать массив объектов POCO) для каждого представления. Если вы решите позже, вам нужно добавить больше столбцов в одно из представлений, тогда вы нарушите существующий код (потому что вы меняете интерфейс на POCO). Если вы решите вернуть представление каждой таблицы и попытаться объединить ее в слое buisness, то это может стать ДЕЙСТВИТЕЛЬНО беспорядочным. У TSQL есть причины для причины:). Кроме того, вы могли бы вернуть гораздо больше данных, тогда вам нужно в зависимости от вашего дизайна, который был бы неэффективен.

У меня есть еще несколько вопросов, но я сохраню это позже. Я не хочу, чтобы этот пост стал большим:)

NCAGE

Ответ 1

Хорошие вопросы. Важные вещи, это. В общем, одним из лучших способов подхода к многоуровневым решениям является просмотр интерфейсов. Интерфейсы - это способ предоставления "chokepoints", который может служить в нескольких полезных целях.

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

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

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

Знание этого делает вещи простыми; используя Plain Old Objects, как правило, ваши интерфейсы будут чистыми и правильными; и это не позволяет вашим структурам данных раздуваться. Он также служит для предотвращения соблазна использовать некоторую информацию об осуществлении одного уровня в другом уровне.

Конечно, чтобы сделать это правильно, полезно долго смотреть на проблему, которая должна быть решена; какой набор операций должен выполнять пользователь? Эти операции обычно разрешают себя в "глаголах", которые хорошо сопоставляются с определениями интерфейсов, которые определяют контракт, который будут реализовывать бизнес-объекты. Наборы данных, на которые будут работать ваши бизнес-объекты, будут определять набор представлений, которые вам нужны для вашей базы данных. Таким образом, вы можете спокойно поддерживать разделение.

Ответ 2

Это очень хорошие вопросы. Существует множество возможных ответов и множество возможных архитектур. Я рекомендую вам прочитать учебник по этому вопросу. У шаблонов и практик есть очень хороший вариант. Он бесплатный, всеобъемлющий и подробно обсуждает вопросы, которые вы задаете. Ни один архитектурный гид не идеален, но, как отправная точка, я не думаю, что вы можете ошибиться, изучая основы.

Ответ 3

Я думаю, вы немного упустили идею о том, что не хотите, чтобы уровень данных знал о бизнесе или уровне пользовательского интерфейса. В инструменте ORM (например, LINQ to SQL) свойства ваших объектов определяются данными. Нет причин не делать этого. Наличие строго типизированных объектов - это не то же самое, что логика бизнес-логики в уровне данных и, как правило, хорошая вещь; как вы добрались до вас.

Я ВСЕГДА рекомендую использовать строго типизированный компонент для передачи данных, а не репозиторий общего назначения, например DataSet/Table/Row/View/etc.

Возможно, вы могли бы немного расширить то, что отвлекло вас от этого подхода?