ASP.NET - Как эффективно использовать шаблоны проектирования без чрезмерного проектирования!

Question

Буду признателен за мысли людей о дилемме, с которой я боролся с тех пор, как вышел ASP.NET.

В классическом ASP уровни кода были минимальными. Страница ASP содержала HTML и скрипт вместе взятые. Компоненты COM содержали бизнес-логику и инфраструктуру DAO . Сами страницы ASP были грязными, но все было в одном месте.

Кодовый компонент ASP.NET нейтрализует код, это нормально. Элементы управления позволяют нам быть более объектно-ориентированными на уровне представления. Эти вещи хороши.

Вот моя проблема. Многие проекты, в которые я заходил, являются корпоративными веб-приложениями, но не такими уж сложными, скажем, около 10 веб-страниц / пользовательских интерфейсов, много взаимодействий с базами данных и т. Д. Раньше это было очень легко понять. Теперь я часто сталкиваюсь с 5-10 слоями кода для создания довольно простой веб-страницы. К ним могут относиться ASP, программный код, управляющие классы, DTO классы, объекты ORM, а затем еще несколько других, которые просто добавили его в ад.

В дополнение к 5-10 слоям для доступа к базе данных существует множество пользовательских объектов, созданных только для хранения обычных данных, вместо использования POCO (простые старые объекты CLR), например, коллекции. , Чтобы понять эти объекты, часто приходится прослеживать через иерархию наследования, включающую 3 или более уровней объектов и интерфейсов.

Вот суть: ранее я посмотрел одну страницу ASP и сказал, что 1 или 2 небольших объекта, несколько запросов SQL, выполнили свою работу и были довольно просты в обслуживании и понимании.

Теперь для одной и той же страницы может быть буквально 50 или более объектов, распределенных по сотням объектов в пользовательском пространстве имен.

Я спрашиваю вас, товарищи-ремесленники, это прогресс? Некоторые люди идут немного за борт с их забавными игрушками нового дизайна? Есть ли счастливая среда? Есть ли способ эффективно использовать шаблоны проектирования, не создавая так много объектов, что он становится хуже кода спагетти, чем старый процедурный парадигна?

Пожалуйста, поделитесь своими мыслями.

Answer 1

Если исключить возможность того, что организации требуются эти уровни абстракции (маловероятно, но это случается), разработчики, особенно в неорганизованных корпоративных средах и средах, очень часто добавляют слишком много уровней абстракция. Это случилось с классическим ASP, .NET просто делает это намного проще. У большинства из нас в этой профессии есть естественная тенденция усложнять вещи, и для преодоления этого требуются дисциплина и активный ум.

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

Наконец, многих посредственных разработчиков учили, что они должны использовать слои, абстракции и шаблоны, но их не учили достаточно хорошо, чтобы знать, как, когда и почему. Поэтому они входят в проект, думая: «Ну, я знаю, у меня здесь должно быть несколько слоев ...», и вы можете себе представить, что получится.

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

Answer 2

Некоторые люди астронавты архитектуры , и они будут настаивать на том, что все эти слои необходимы, а дизайн - абсолютный мусор, если вы их не включите.

На другом конце спектра находятся люди, которые отодвигают все это в сторону и просто объединяют весь код: это просто, верно, так почему бы просто не разместить SQL-запрос прямо в коде, заполняющем список контроль?

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

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

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

Создание нормального бизнес-уровня - хороший шаг к достижению этой цели. Это должен быть слой, который представляет простейшее представление объектов в вашей системе и не содержит общедоступных объектов, связанных с базой данных (кроме, возможно, объекта Connection, который сообщает бизнес-уровню, как добраться до базы данных). Это объединяет всю вашу логику в одном месте, поэтому ASP-часть проекта просто подключит абстрактный метод «User.LoadAll ()» к таблице, в которой отображается список пользователей. Приложение ASP не должно иметь ни малейшего понятия, читает ли оно из базы данных, веб-службы или просто кучу готовых вещей ... оно просто взаимодействует с бизнес-уровнем.

На бизнес-уровне у вас могут быть запросы напрямую, вы можете использовать ORM, вы можете создать более глубокий уровень доступа к данным, который выполняет эти вещи ... хорошо, что это решение целиком содержится на бизнес-уровне (и вы можете измените его позже, если это необходимо, не затрагивая общедоступный API бизнес-уровня).

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

Я только что выполнил миграцию, как я описал выше (ASP с SQL в выделенном коде, на отдельный уровень представления - бизнес - источник данных (ORM)), и это здорово. Хотя это добавляет несколько уровней для получения реальной информации, как только бизнес-методы работают, остальная часть кода работает. Исправить ошибку просто, и исправляет ее везде. Ближе к концу это быстро привело к тому, что, когда вам нужно было получить список отчетов, которые может запустить пользователь, кто-то уже написал для этого бизнес-метод (User.GetReports ()), где раньше вы, вероятно, никогда найдите его, если это было сделано - если вам повезло, он был написан как функция, а не просто встроенный код.

Answer 3

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

С другой стороны, чтобы ответить на ваши вопросы о шаблонах проектирования:

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

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

В качестве отступления: если вы хотите отличный пример чрезмерного дизайна, посмотрите на исходный код приложения CruiseControl.NET в трее. Это отличная демонстрация безумных шаблонов проектирования (если честно, Thoughtworks в целом - отличная демонстрация этого).

Answer 4

Для меня проблема возникла из-за слишком большого количества статей, в которых автор не нашел времени, чтобы объяснить контекст, в котором было найдено решение.

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

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

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

Answer 5

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

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

Главное, что ASP.NET гораздо лучше помогает разработчикам безопасно повторно использовать код, чем Classic ASP, поэтому не удивляйтесь, когда они этим воспользуются.

Теперь это на самом деле не решает вашу проблему с перебором с многоуровневым дизайном. На самом деле я думаю, что это зависит от ситуации. Если ваш веб-сайт - это система only , обращающаяся к базе данных, и она не такая большая, то, возможно, это излишне. Но даже в этом сценарии большая часть кода данных и бизнес-уровня может быть написана с помощью решения ORM , и это хорошо, поскольку такой код, как правило, не содержит ошибок и может быть перенесен в какой-то темный угол вашей ревизионной системы и забыли. Затем, когда (а не «если») сайт превращается во что-то, что может фактически использовать хорошо построенный слой данных, этот код уже существует для его поддержки при очень небольших затратах на производство или обслуживание.

С другой стороны, если ваш веб-сайт совместно использует доступ к базе данных с помощью корпоративного программного обеспечения для отчетов или настольного приложения Windows для управления, или несколько небольших приложений взаимодействуют с одной и той же базой данных, то, возможно, весь этот «дополнительный» код служит цель. Основная причина написания данных и кода бизнес-уровня заключается в том, что этот код может быть разделен между каждой из различных систем, которые взаимодействуют с базой данных, так что этот код реализован в одном месте. Может быть, это много кода, чтобы написать для небольшого веб-сайта, но в этом случае он не был написан для этого сайта. Он был написан для среды, в которой сайт & mdash; и несколько других приложений & mdash; работает.

Answer 6

Я думаю, что было бы трудно использовать шаблоны проектирования, с которыми я знаком в Classic ASP, поэтому в этом отношении мы впереди игры.

Хотя я не использовал реализацию MVC в ASP.NET, я понимаю, что она решает многие ваши проблемы, поскольку она гораздо более прямая и простая.

Answer 7

Это пример общего принципа более высокого уровня, я думаю.

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

Все сильное создает потенциал для блага и блага ... в противном случае.

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

Answer 8

Цель всех названных вами инструментов и методов - управлять сложностью в мире быстро меняющихся бизнес-требований. Характеризуют ли «сложность и быстро меняющиеся бизнес-требования» мир, в котором находятся ваши приложения?

Answer 9

По моему опыту, вы будете намного более гибкими, вообще не используя пользовательские объекты базы данных. В более старых версиях .NET вы можете передавать объекты DataTable. В .NET 3.5 вы получаете бесплатные типы с помощью LINQ.

Удивительно, как некоторые разработчики тратят 75% своего времени на получение данных из базы данных. Какой .NET прекрасно работает без какого-либо пользовательского кода. Используйте стандартную библиотеку, и у вас будет гораздо больше времени для решения бизнес-задач.

Answer 10

Спасибо за все комментарии. Чтобы уточнить немного, в классическом ASP мы использовали компоненты VB, что, естественно, ограничивало нашу способность их чрезмерно усложнять, что было хорошо в том смысле, что это делало его проще.

Мне понравился ответ Рекса: «В конечном итоге,« лучшая практика »лучших практик - это как можно более простой код, пока вы не столкнетесь с реальной проблемой, мешающей вам двигаться вперед».

Это звучит похоже на другое, которое я слышал: «Преждевременная оптимизация - корень всего зла».

После этого, что если мы просто поместим всю логику шины в код позади и затем переместим ее в разделяемые библиотеки, когда обнаружили, какой код действительно будет использоваться несколькими страницами? Например, если это одна страница, вы можете иметь все в коде позади. Если есть две страницы, которые разделяют одну логику, создайте компонент. Если два компонента используют SQL Server, создайте один новый компонент для оптимизации запросов SQL и т. Д.

Мне также понравилось различие Даны по созданию пользовательских приложений по сравнению с одним приложением. Одно дело иметь полноценный API, если его будут использовать 1000 других. Это может быть пустой тратой времени на использование одной и той же энергии в одном приложении.

«Архитектурные астронавты» - отличный термин для сверхинженерной тенденции!

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

Еще один связанный с этим вопрос, который я хотел бы затронуть: как насчет простого использования объектов POCO (предоставляется .NET) для хранения данных в архитектуре ASP.NET. Я видел, как некоторые архитектуры создают новый объект для каждого типа обмена данными. Разве не проще было бы просто создать объект коллекции (скажем, список) и назвать его «эти данные», «эти данные» и т. Д .?