Администрация области в Asp.Net MVC - PullRequest
27 голосов
/ 25 мая 2009

Мой вопрос может быть очевиден, но я хотел бы создать хорошо разработанное веб-приложение. Как и в любой области администрирования, администратор должен иметь возможность перечислять / создавать / удалять / изменять пользователей, статьи, сообщения и т. Д. *

Я бы хотел знать, как лучше всего разработать приложение. Должен ли я создать контроллер для каждого из этих элементов (/ Users / Create / id или / Posts / Delete / id) или создать все действия в моем контроллере администратора (/ Administration / CreateUser / id или / Administration / DeletePost / id)?

Ответы [ 8 ]

14 голосов
/ 25 мая 2009

Вы должны написать отдельный контроллер для каждой сущности, чтобы сохранить четкое разделение проблем для ваших классов контроллеров. Если у вас есть только один контроллер, то у вас будет только один каталог Views с десятками представлений, а ваш контроллер будет содержать десятки методов, и это скоро станет неуправляемым.

1 голос
/ 25 мая 2009

В настоящее время я использую ASP.NET для большого клиента.

Подход, который я принял, состоит в том, чтобы поместить функциональность действия в другой класс.

Пример

Я также пишу раздел администрирования. Будет один контроллер администрирования (наш раздел администрирования небольшой, если бы он был больше, я бы изменил маршрутизацию, чтобы позволить больше контроллеров, сейчас мы используем готовую конфигурацию). Если я создаю представление «EditUser». Я также создам «EditUserAction» class . Весь код EditUser перейдет в класс. Я создаю класс EditUserAction в классе контроллера администрирования в методе Edit User. Это удаляет весь код, специфичный для действия, из класса Controller. Таким образом, весь код, специфичный для действия, находится либо в методе действия, либо в классе действия. В противном случае контроллер быстро переполнится кодом из различных действий. Класс контроллера в короткие сроки превратился бы в неуправляемый беспорядок.

Примеры классов

public class Administration: Controller
{
    public ActionResult EditUser(string userId)
    {
        EditUserAction action = new EditUserAction();
    }
}

public class EditUserAction
{
    public void Save(User user)
    {   
        //save code here
    }
}

Надеюсь, это объяснение понятно. Если это не так, дайте мне знать, и я уточню.

На ответ на ваш вопрос я делаю это последнее ( / Administration / CreateUser / id или / Administration / DeletePost / id ).

1 голос
/ 25 мая 2009

Я бы просто создал новый веб-сайт MVC, который занимается администрированием. У вас есть более гибкое решение, если вы разделяете данные и бизнес-логику в разных сборках. Затем вы можете опубликовать свой сайт на поддомене, например, admin.yoursite.com. Таким образом, вам не нужно связываться с вашими маршрутами, и вы можете держать их в отдельных представлениях, что является наиболее элегантным решением imho. Про и Кон было бы приятно услышать.

Я работаю над проектом, который будет нуждаться в том же сайте администрирования, но пока не зашел так далеко, поэтому этот вопрос меня очень интересует.

1 голос
/ 25 мая 2009

Ответ зависит от того, сколько функциональности будет в контроллерах. Просто начните с одного контроллера, и если он становится слишком большим, разделите его на несколько. Самое замечательное в MVC заключается в том, что когда вы помещаете вещи в свои контроллеры, они не должны влиять на URL. Вы можете очень легко отобразить / Пользователи / Создать, например, на. Класс UserAdminController.

0 голосов
/ 08 июля 2013

Зависит от размера вашей админки, Я предлагаю вам рассмотреть возможность сделать следующее (или, может быть, немного документировать)

  • Подумайте, сколько объектов вы хотите управлять независимо,
  • Подумайте, сколько действий будет иметь каждое,
  • Проверьте, есть ли какая-либо зависимость между вашим приложением и областью администратора (доступ пользователя, для удобных URL-адресов)

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

* Если масштаб проекта быстро растет, и вскоре он требует большого масштаба, я бы выбрал третий - с новым проектом admin mvc.

Надеюсь, это поможет вам решить.

0 голосов
/ 11 августа 2009

Предлагаю использовать это решение .

Но я изменил определение на это:

    public ThemedViewEngine()
    {
        base.MasterLocationFormats = new string[] {
            "~/Views/{1}/{0}.master", 
            "~/Views/Shared/{0}.master",
            "~/Themes/{2}/Views/{1}/{0}.master", 
            "~/Themes/{2}/Views/Shared/{0}.master",
            "~/Themes/Default/Views/{1}/{0}.master", 
            "~/Themes/Default/Views/Shared/{0}.master"
        };
        base.ViewLocationFormats = new string[] { 
            "~/Views/{1}/{0}.aspx", 
            "~/Views/{1}/{0}.ascx", 
            "~/Views/Shared/{0}.aspx", 
            "~/Views/Shared/{0}.ascx",
            "~/Themes/{2}/Views/{1}/{0}.aspx", 
            "~/Themes/{2}/Views/{1}/{0}.ascx", 
            "~/Themes/{2}/Views/Shared/{0}.aspx", 
            "~/Themes/{2}/Views/Shared/{0}.ascx",
            "~/Themes/Default/Views/{1}/{0}.aspx", 
            "~/Themes/Default/Views/{1}/{0}.ascx", 
            "~/Themes/Default/Views/Shared/{0}.aspx", 
            "~/Themes/Default/Views/Shared/{0}.ascx" 
        };
        base.PartialViewLocationFormats = new string[] {
            "~/Views/{1}/{0}.aspx",
            "~/Views/{1}/{0}.ascx",
            "~/Views/Shared/{0}.aspx",
            "~/Views/Shared/{0}.ascx",
            "~/Themes/{2}/Views/{1}/{0}.aspx",
            "~/Themes/{2}/Views/{1}/{0}.ascx",
            "~/Themes/{2}/Views/Shared/{0}.aspx",
            "~/Themes/{2}/Views/Shared/{0}.ascx",
            "~/Themes/Default/Views/{1}/{0}.aspx",
            "~/Themes/Default/Views/{1}/{0}.ascx",
            "~/Themes/Default/Views/Shared/{0}.aspx",
            "~/Themes/Default/Views/Shared/{0}.ascx"
        };
    }

Тема по умолчанию используется по умолчанию, поэтому она должна существовать.

Структура каталога будет:

  • Содержание
  • Темы
    • По умолчанию
      • Содержание
      • Просмотров
        • Главная * * 1023
        • Блог
        • Все, что должно быть очищено от кожи
    • OtherTheme
      • Содержание
      • Просмотров
        • Главная
        • Блог
        • Все, что должно быть очищено от кожи
  • Просмотров
    • Статья
    • Сообщения
    • Пользователи
    • Настройки
    • Другие административные материалы
0 голосов
/ 25 мая 2009

Вот еще один способ задать мой вопрос.

Часть моей мастер-страницы:

<% if (!String.Equals(ViewContext.RequestContext.RouteData.GetRequiredString("controller"), "Administration")) { %>
<div>
    <!-- Some Code -->
</div> <% } %>

Как вы можете видеть, на моей главной странице я хотел бы отобразить некоторую часть страницы, в зависимости от того, работает пользователь в области администрирования или нет. Он работает довольно хорошо только с контроллером администрирования (/ Administration / CreateUser / id) ... но становится большим беспорядком, когда я использую другой контроллер в качестве пользователя или статьи (/ User / DeleteUser / id или / Article / Details / id) .

Я бы предпочел использовать один контроллер для каждой сущности, но я не могу найти способ связать этот подход с несколькими контроллерами.

0 голосов
/ 25 мая 2009

Вы можете использовать DynamicData для этого. Это не MVC, но его можно использовать вместе с ним, и его очень легко установить и использовать.

...