Объектно-ориентированное проектирование имеет место в веб-разработке? [закрытый]
Я работаю в магазине веб-разработки так естественно, мы имеем дело с профилями пользователей. При контакте с одним из наших сайтов я заметил, что не было никакого 'Пользовательского' класса, который показался мне нечетный, так как у нас, конечно, есть пользователи. Вместо этого сайт полагается на взаимодействие с DataRows (это - C#), возвратился через статические методы с мало ни к какому инстанцированию. Я спросил своего босса о создании класса для пользователей, и его ответ состоял в том, что начиная с объектов должны быть восстановлены так часто не стоящий того.
Я относительно плохо знаком с веб-разработкой, и на что-то вроде отходов действительно походит должным быть инстанцировать объектов каждый раз, когда страница восстановлена, но с другой стороны я всегда находил, что объектно-ориентированное программирование полезно. Таким образом, мне любопытно для некоторых мнений, сколько делает Вас, парни используют ООП в веб-разработке?
4 ответа
Единственный раз, когда я не использую ООП, это когда:
я создаю простой проект для проверки какой-то логики. Обычно это приводит к созданию нужных классов...
Я использую Classic ASP (давно, слава Богу).
Я не программирую.
edit Спустя 3+ года после публикации вышесказанного, я немного прибавлю к своему ответу.
ООП - это здорово и позволяет нам иметь огромное количество гибкости для взаимодействия нескольких систем с одними и теми же данными/логикой. Однако, безусловно, есть ситуация, в которой вам не хотелось бы утруждать себя загрузкой множества объектов... А именно, когда вы просто тянете данные для табличного отображения.
Запрос базы данных и получение простого набора записей, который немедленно передается в браузер, обычно не требует участия ООП. На самом деле, вы можете захотеть полностью обойти ООП, так как табличные данные обычно включают в себя свертывание другой информации (суммы дочерних записей), и вы обычно не хотите вытягивать больше данных из базы данных, чем то, что вы на самом деле используете. Т.е. если вы показываете только имя и электронную почту, вы, вероятно, не захотите вытягивать имя пользователя, так как это просто пустые циклы.
Теперь, помещение информации в БД обычно включает в себя уверенность, что соблюдается определенная логика ведения бизнеса. Например, что имя пользователя следует определенным правилам. В таких ситуациях использование стиля ООП делает вещи немного более инкапсулированными и легко переносимыми между системами.
Итак, посмотрим на конкретный пример: Я бы не стал беспокоиться больше, чем о передаче данных ретранслятору при перетаскивании данных; но у меня был бы пользовательский класс для тех случаев, когда я собираюсь создать новый или оперировать с этим пользователем, чтобы удостовериться, что бизнес-правила соблюдаются должным образом
.ООП не более чем парадигма программирования !! но его значение заключается в том, что фактическая парадигма в использовании подразумевает, что все современные знания и лучшие практики в программной инженерии будут выражаться следующим образом ...
Хорошим примером в вашем случае (веб-разработка) является Core J2EE Patterns.
(источник: sun.com)
Конечно. Вы (и, более того, ваш босс) говорите "перестройка", как будто это огромная рутина.
Под "перестройкой" вы подразумеваете запуск программы. Скажите своему боссу, что ООП в целом глупа, потому что даже в окружении рабочего стола каждый раз, когда кто-то запускает программу, объекты нужно перестраивать, так что это даже не стоит того.
.Комментарий босса бесполезен. Фреймворк .net состоит из объектов и ничего больше. Ответ" - это объект, даже в "классическом ASP" - зачем бы люди его реализовывали, если бы этот ресурс был неэффективен?
.