Где я должен разместить свои служебные классы в приложении ASP.NET MVC3?

Я разрабатываю веб-приложение в ASP.NET MVC3 с С# и Razor.

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

В веб-формах ASP.NET я помещал такие классы в папку App_Code. В MVC такой папки нет, и я не думаю, что служебные классы не относятся ни к Моделям, ни к Помощникам (папка, которую я создал, чтобы поместить мои расширения для HTML-помощников).

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

Однако в моем случае мне просто нужно поместить один единственный класс с несколькими методами, поэтому, если мы проигнорируем возможность повторного использования, не будет ли логичнее разместить служебный класс где-нибудь в моем веб-приложении MVC3?


asp.net-mvc-3 class-library code-reuse utility-method
person CiccioMiami    schedule 10.02.2012    source источник

Ответы (4)


arrow_upward
12
arrow_downward

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

Я обычно создаю папку под названием «HtmlHelpers» или «Инфраструктура» для сантехники.

Папка «Общие» похожа на мусорную корзину. Ты кладешь в него весь хлам.

Обновлять

Я бы поместил его в метод расширения для DateTime (помещенный в класс с именем DateTimeExtensions, который помещен в пространство имен, называемое Infrastructure).

И я бы использовал его внутри модели представления или при создании модели представления (в контроллере).

Что касается проекта, это не имеет большого значения. Важно то, что у вас есть небольшие классы с конкретными задачами (или обязанностями).

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

Другими словами: я бы поместил своих помощников в Ядро (проект бизнес-логики) в пространство имен под названием Инфраструктура.

person jgauffin    schedule 10.02.2012
comment
Спасибо! Я использую методы расширения для своих HTML-помощников, а также ViewModels, чтобы вообще не использовать Viewbag, поскольку я выполняю модульное тестирование. Поскольку вы предлагаете не использовать служебные классы (я читал много дебатов в Интернете), где бы вы разместили класс, который предоставляет методы для преобразования строки в даты, например, путем извлечения года? - person CiccioMiami; 10.02.2012
comment
супер! Вы зашли далеко тогда. Я бы поместил его в метод расширения для DateTime (помещенный в класс с именем DateTimeExtensions, который помещен в пространство имен с именем Infrastructure). И я бы использовал его внутри модели представления или при создании модели представления (в контроллере). - person jgauffin; 10.02.2012
comment
Отличная организация! Однако я забыл добавить, что использую эти классы в своем DataRepository (или DAL), поскольку человек, создавший базу данных, которая предоставляет данные для приложения, сохранил все даты в виде строки. Поэтому, если у меня есть метод GetAllProductsCreatedThisYear, мне нужна функция, которая преобразует строку в дату в моей встроенной функции LINQ. Применяется ли ваша организация и в этом случае? - person CiccioMiami; 10.02.2012

arrow_upward
1
arrow_downward

Назовите это Common, поместите туда все.

Затем используйте пространства имен, подобные этим примерам.

Common.Formatters Common.Functions Common.Foo Common.Bar

person Doug Chamberlain    schedule 10.02.2012
comment
Спасибо! Я тоже думал об этом, но поскольку мы больше людей, работающих над одним и тем же проектом, я хотел бы иметь сильную и четкую структуру именования, чтобы иметь четкое разделение задач между папками, помимо пространств имен. - person CiccioMiami; 10.02.2012

arrow_upward
1
arrow_downward

Почему бы вам не создать еще одну папку с именем Utility, Infrastructure или аналогичную в вашем проекте (например, рядом с папкой Helpers) и поместить туда служебные классы.

Вы всегда можете переместить его в отдельную DLL (проект библиотеки классов), если вам понадобится повторно использовать его.

person M4N    schedule 10.02.2012
comment
Спасибо, это тоже была моя первая мысль, но, поскольку я думаю, что многие разработчики оказались в такой же ситуации, как и я, я хотел узнать больше мнений о любом стандарте или передовом опыте, применимом к этому. - person CiccioMiami; 10.02.2012

arrow_upward
0
arrow_downward

Я предпочитаю создавать папку и пространство имен под названием Helpers, как предлагается здесь: Где я могу поместить пользовательские классы в ASP.NET MVC?

person Chris Goodman    schedule 11.02.2015