Это действительно профессионально для использования средств управления источником данных в ASP.NET? [закрытый]

These controls have gained a bad reputation due to inexpert developers using them without understanding them, and professional developers looking down on them as a result. The best advice I can give you, is that a professional will use whatever tool is the most appropriate, and which gets the job done without getting in the way. If these tools do the job for you, then you should use them and don't let people put you down for it.

I think one could argue that using ObjectDataSource is reasonable, presuming it is actually talking to a real middle-tier of objects. Especially if the developers extend ODS to play with their middle-tier.

The others will get your fingers broken (2nd offense) in my shop.

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

Первое, что вам нужно понять об ASP.NET, это то, что все, что связано с серверными элементами управления и парадигмой веб-форм в целом, никогда не будет работать так же хорошо, как Response.Write (). Вся идея веб-форм состоит в том, чтобы как можно быстрее доставить вас из точки А в точку Б. Итак, прежде чем выбирать веб-формы, вы должны спросить себя, является ли это лучшим фреймворком для моего приложения? Для веб-сайтов с высоким трафиком и / или если вы сильно заботитесь о шаблонах проектирования, я бы без сомнения выбрал MVC.

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

They are great for populating a bound control if the query is simple, like a dropdown list of categories. They are rather painful for doing custom searches or the like. Evaluate your approach on a case by case basis.

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

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

Personally I prefer to wire stuff up myself. It is pretty simple to run stored procs to retrieve data and assign it to data entry controls without using data binding. It is also easy to grab the modified data and add, update, or delete as needed. The data source classes add what seems to me to be an unnecessary extra layer. If they were significantly simpler than the way I do it I might give them a shot, but they seem pretty complex to me. And, even though I don't have any benchmark data to prove this, it seems they must be less efficient.