Это может быть широкий вопрос, потому что отчасти проблема в том, что я на самом деле не знаю, что это за вопрос. Я хотел бы знать, как вы обычно организуете приложения ASP.NET с точки зрения размещения страниц (aspx), пользовательских элементов управления (ascx), серверных элементов управления и других вспомогательных классов, служебных функций и т. Д. Во-первых, давайте предположим, что уже есть где-то слой данных (возможно, в другом проекте). Это не проблема.
Проблема, с которой я часто сталкиваюсь, заключается в том, что нужно создать несколько страниц и понять, что им нужно совместно использовать некоторую общую логику рендеринга или некоторую служебную функцию, класс и т. Д. Другой типичный случай заключается в том, что некоторые страницы становятся слишком большими, поэтому их удобно разделить (скажем, некоторые пользовательские элементы управления). Как лучше всего разместить эти служебные классы, классы общего доступа, пользовательские элементы управления, элементы управления сервером и т. Д.? Вот несколько возможностей.
На самом деле не заботьтесь о какой-либо организации и размещайте все типы файлов рядом друг с другом. Так что в одном каталоге у вас могут быть файлы aspx, некоторые файлы cs и т. Д. Вероятно, это не совсем вариант.
Организация файлов по типам. Допустим, вы создали каталог для пользовательских элементов управления и разместили там все пользовательские элементы управления. Хорошо, а как насчет серверных элементов управления и других обычных классов? Должны ли они быть в специальных каталогах, а? Это не звучит правильно. Что мне больше всего не нравится в этом, так это то, что когда вы работаете над функцией (логически связанным фрагментом кода), вы должны охотиться за ней повсюду. Я думаю, что функции и логические разделы ваших приложений также должны быть каким-то образом сгруппированы на уровне файловой системы.
То, что я хотел бы иметь, - это иметь страницы (aspx), пользовательские элементы управления (ascx) и обработчики (ashx) в основном как фиктивные заполнители, расположенные в структуре каталогов, логически организованные в соответствии с точкой зрения внешней стороны. посетителя, в то время как фактический код (страница, реализации пользовательских элементов управления, управляющий класс обслуживания и служебные классы) должен быть помещен в другую папку, структурированную в логические пространства имен (организованные модулями или функциями приложения). Мне кажется, что единственный способ достичь этого - манипулировать директивой <%@ Page ... %> вручную.
Звучит безумно? Я слишком много спрашиваю? Есть ли способ лучше? Каковы ваши лучшие практики? Вы знаете несколько хороших примеров?
Редактировать: Еще одна идея. Это не портит сгенерированные файлы aspx, aspx.cs и aspx.designer.cs. Одно из моих первоначальных требований состояло в том, что я хотел разместить код, управляющий aspx-страницами, в своем собственном местоположении и поместить его в пользовательскую иерархию пространства имен. Так что, если я просто создаю подклассы классов aspx, сгенерированных VS? Допустим, у меня есть проект под названием MyApp и MyPage.aspx page. VS создает MyApp.MyPage унаследованное от System.Web.UI.Page. Я оставляю этот класс (без кода), но создаю подкласс, скажем, в MyApp.SomeNamespace.SomeSubNamespace.MyPage, унаследованный от MyApp.MyPage. Таким образом, MyApp.SomeNamespace.SomeSubNamespace.MyPage получит доступ к автоматически сгенерированным защищенным полям, соответствующим серверным элементам управления MyApp.MyPage, и я получу полное «личное» пространство имен для всех классов поддержки, связанных с этой страницей. Есть ли серьезные недостатки? Другая проблема, которая беспокоит меня, это где физически разместить этот новый файл cs? В веб-проектах для него есть стандартная папка App_Code, но я заинтересован в веб-приложениях. Создание каталога в корне приложения (например, кода) не звучит правильно.