ASP.net структура проекта MVC
вот способ, которым выполняют в разбиении на страницы, в спящем режиме
Query q = sess.createQuery("from DomesticCat cat");
q.setFirstResult(20);
q.setMaxResults(10);
List cats = q.list();
, можно добраться, больше информации от в спящем режиме документы в: http://www.hibernate.org/hib_docs/v3/reference/en-US/html_single/#objectstate-querying-executing-pagination 10.4.1.5 и 10.4.1.6 раздела дают Вам больше flexbile опций.
BR,
~A
3 ответа
У меня аналогичная структура у вас с некоторыми исключениями:
- Поддержка называется Инфраструктура (пространство имен только для использования сборки пользовательского интерфейса)
- IoC находится в другом проекте (проект для глобально используемых функций инфраструктуры ). Пользовательский интерфейс имеет реестр StructureMaps только с именами сборок (IoC инициализируется по соглашению). Подходите вроде украденного из исходников CodeCampServer. Здесь также находятся разделы журнала и конфигурации.
- Views / [ControllerName] имеет подпапку Partial, которая может быть еще больше разделена
(это включает в себя манипуляции с ViewEngine, чтобы он мог найти представления / частичные представления.)- Views / [ControllerName] имеет папку LocalResources (с подпапкой Partial)
- Не добавлены подпапки в Controllers (... пока). Мне нравится, чтобы они были чистыми и довольно глупыми.
И еще несколько исключений, связанных с моделью:
- Вся бизнес-логика находится в сборке домена, пространстве имен Domain.Model с некоторой помощью уровня инфраструктуры для технических аспектов.
- Модели представлений (я называю их ViewData) находятся в сборке пользовательского интерфейса в папке ViewData, структурированы в папках, как и представления. Выбранный подход от Kigg (за исключением того, что я структурирую их для каждого представления, например SearchViewData, иногда даже для частичного представления).
Пока он работает достаточно хорошо
Обратите внимание, что структурирование ViewData (я даже структурирую свой javascript таким же образом, View == JS файл, который содержит все, что находится под объектом с именем [ViewName]) для каждого представления может быть неприемлемым для более сложных веб-сайтов.
Ой ... и => папка == пространство имен для меня. Думаю, это хорошая практика.
Я ' я написал пару (небольших) сайтов и просто придерживался той же структуры, что и у NerdDinner, и, похоже, все работало нормально.
Я думаю, что для небольших проектов это хороший подход, если у вас есть разделение проблем, не надо. • разместить бизнес-логику в репозитории (репозиториях) и т. д. В небольшом проекте возникает соблазн размыть границы, но MVC имеет тенденцию немного наказать вас, когда вы это делаете. :)
В более крупных проектах может быть реализован отдельный проект бизнес-класса и, возможно, даже проект преобразования данных и т. Д.
Я думаю, что это немного слишком сложно, но если это имеет для вас смысл, продолжайте. Главное - соблюдать баланс.
Мне нравится использовать отдельные проекты в рамках решения, так как оно позволяет повторно использовать доступ к данным и бизнес-логику для повторного использования другими типами клиентских приложений, такими как WPF или WinForms Clients.