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

Question

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

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

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

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

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

NCAGE

Answer 1

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

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

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

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

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

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

Answer 2

Это очень хорошие вопросы. Есть много возможных ответов и много возможных архитектур. Я рекомендую вам прочитать учебник по этой теме. Patterns & Practices имеет очень хороший . Это бесплатно, всесторонне и подробно обсуждает вопросы, которые вы задаете. Ни одно руководство по архитектуре не является идеальным, но в качестве отправной точки я не думаю, что вы можете ошибиться, изучая основы.

Answer 3

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

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

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