ASP.NET — Как эффективно использовать шаблоны разработки без сверхразработки!

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

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

No это не прогресс. Да, некоторые люди идут за борт. Вероятно, существует золотая середина, но она требует, чтобы зубрилы шаблона разработки мира успокоились немного, я думаю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

, Хотя я не использовал реализация MVC в ASP.NET, это - мое понимание, что это обращается ко многим Вашим проблемам, в которых это является намного более прямым и простым.

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

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

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

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

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

, С другой стороны, если Ваш веб-сайт совместно использует доступ к базе данных с программным обеспечением создания отчетов предприятия, или настольное приложение Windows для управления или несколько небольших приложений, говорят с той же базой данных, то, возможно, весь этот "дополнительный" код служит цели. Большая причина записи данных и бизнес-кода уровня состоит в том, что этот код может затем быть общим для каждая из различных систем, которые говорят с базой данных, такой, что этот код реализован точно в одном месте. Возможно, это - много кода для записи для небольшого веб-сайта, но в этом случае он не был записан для того сайта. Это было записано для среды в который сайт — и несколько других приложений — выполнения.

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

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

Что-либо мощное создает потенциал для большей пользы и больше... иначе.

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

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

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

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

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

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

мне понравился ответ Короля "В конечном счете, "лучшая практика" лучших практик должна кодировать максимально максимально, ПОКА Вы не сталкиваетесь с настоящей проблемой, которая препятствует тому, чтобы Вы продвинулись".

Это звучит подобным другому, я слышал, который был оптимизацией “Premature, корень всего зла. ”

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

мне также понравилось различие Dana о создавании пользовательских приложений по сравнению с отдельным приложением. Это - одна вещь иметь законченный API, если 1 000 других будут использовать его. Это могла быть пустая трата времени для помещения той же энергии в ту от приложения.

"Астронавты архитектуры" большой термин для сверхтехнической тенденции!

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

Еще один связанный вопрос, который я хотел бы поднять: Как насчет того, чтобы просто использовать ПОСТЕПЕННО (обеспеченная.NET) возражает, чтобы хранить данные в архитектуре ASP.NET. Я видел, что некоторая архитектура создает новый объект для каждого типа межстанционных данных. Разве не было бы более просто просто создать объект коллекции (скажите, что список), и называют его "этими данными", "thatdata", и т.д.?