Вы могли попробовать аутентификацию Oracle прокси, где клиент JDBC аутентифицирует использование сертификата против известного компонента/сервиса среднего уровня (прокси), которому доверяет сервер базы данных. Я никогда не пробовал это, хотя, таким образом, я не знаю, легко ли сделать.
Повторители хорошо вписываются в подход кода программной части. Я провел много лет, не вынося вида любого кода в разметке. Весь код находился в коде программной части, отделенном от разметки. В значительной степени это было реакцией на ужасные беспорядки, с которыми я имел дело в классическом ASP.
Теперь с ASP.Net MVC я обнаружил, что возвращаюсь именно к тому, что вы описали выше. Но мне трудно преодолеть инстинкт разделять разметку и код.
Изменить: Вот статья 2003 года о дебатах по поводу кода программной части.
Я думаю, что основная цель ретрансляторов - не допускать попадания процедурного кода в представление / разметку. Идея состоит в том, что кто-то, кто является графическим / эстетическим дизайнером, может прийти и изменить разметку, не зная, как «кодировать». Возможно, вас больше беспокоит то, что многие люди в мире .NET знакомы с ретранслятором, а это значит, что им будет проще поддерживать его.
Ну, с одной стороны, использование '<% code здесь%> 'слишком много в ASP.NET, это в основном возврат к старым временам asp. В нем перемежаются код и отображение, что затрудняет чтение страницы.
Таким образом, если вы работаете с выделенным кодом, вам нужно создать теги сервера или теги HTML, назначить их динамически и т. Д. И вы получите гораздо больше кода, чем если бы вы просто использовали повторитель.
Повторители также упрощают использование встроенной глобализации .NET, поскольку большая часть их текста автоматически добавляется в файлы resx через ' Инструмент «Создать локальный ресурс» в режиме разработки VS. Это также позволяет избежать возможности недопустимых состояний просмотра, вызванных созданием тегов в коде программной части.
Изменить (в ответ на комментарий):
Встроенная глобализация .NET использует файлы ресурсов (.resx) для хранения частей страницы (обычно текст), такой как заголовок страницы, свойства тега и все остальное, что можно глобализировать.
Затем вы создаете дополнительный файл resx для каждого поддерживаемого вами языка (французский будет «pagename.aspx.fr. resx ', испанский будет' pagename.aspx.es.resx 'и т. д.), а .NET определит язык браузера пользователя во время выполнения и будет использовать строки из файлов resx (начиная с наиболее конкретных, которые он может, и снижая до значения по умолчанию ) для замены свойств в тегах сервера.
Например, если у вас есть тег сервера с текстом '
Основное преимущество повторителя заключается в том, что вы генерируете несколько элементов управления ASP.NET внутри указанных циклов.
Но для большинства его применений это просто другой способ делать именно то, что вы делаем.
Причина использования повторителей вместо петли сводится к основным различиям в философии кодирования. Хотя наличие цикла в коде определенно не отправит вас в ад программистов, он просто может отправить вас в ад ASP.NET, поскольку нарушает разделение кода HTML и данных.
Я думаю, что вы будете find с помощью веб-элементов управления ASP.NET заключается в том, что они предоставляют множество инфраструктуры .
Для вашего случая использования цикл for может быть идеальным.
Но для более сложных проблем форматирования и методов разработки может быть полезно, чтобы объект (Repeater) завершал всю функциональность вашего цикла for и предоставлял множество дополнительных функций в виде кода программной части с поддержкой Intellisense. .
Microsoft часто пытается максимизировать то, что вы можете делать без программирования. Вы можете многое сделать с репитерами без кода программной части. С элементами управления источниками данных вы можете многое сделать вообще без кода. Можно предположить, что в качестве корпоративной стратегии они хотят иметь самую простую в использовании среду разработки, а «никакого кода вообще», очевидно, чье-то определение простоты использования.
Но когда вы хотите выйти за рамки бесплатного автоматического поведение вы по колено в модели события с множеством извилистых проходов, которые все выглядят одинаково. Мне нравится девиз Perl: «Делайте простые вещи простыми, а сложные - возможными», и Microsoft иногда, кажется, предпочитает «делать простые вещи тривиальными, а все остальное - сложными».
Некоторые упоминали, что ASP.Net MVC уходит от этого.
Метод Asp.Net веб-разработки отличается от Rails тем, что традиционный ASP.Net не основан на MVC. Вы можете делать MVC, используя традиционный ASP.Net, однако это сложно и неуклюже (обычно). Это то, что привело к созданию инфраструктуры ASP.Net MVC, чтобы заполнить это пространство.
Повторитель был хорошим элементом управления для традиционного ASP.net, поскольку он обеспечивал лучшую производительность и больше возможностей, чем другие элементы управления привязкой к данным. В некоторых случаях это также обеспечивает лучшую разметку. Как уже говорили другие, он обеспечивает большую инфраструктуру, а также четкое разделение между разметкой и кодом.
На самом деле нет ничего плохого в том, что вы делаете; однако, если вы используете традиционный ASP.Net, а не mvc ASP.Net, человек, который поддерживает код после вас, может быть не слишком счастлив.
Код в ASPX в основном декларативный / разметочный. Это обычно легче поддерживать, особенно членам команды, не имеющим большого опыта программирования. Работа с разметкой также помогает разделить проблемы (например, MVC).
Если вы используете .Net 3.5, я считаю, что повторители в значительной степени заменены ListView .
Если вы используете asp.net MVC и вам предлагается использовать повторитель, то человек, который говорит вам это сделать, вероятно, является классическим человеком ASP.net.
В MVC единственные элементы управления, которые вы должны использовать, - это
и использование пользовательских элементов управления вместо render: partial => "foo"