Типичная структура решения ASP.NET?
Вы можете использовать это ; указатель на объект, над которым вы сейчас работаете. как показано ниже.
this->setMessage(fileMessage);
или
(*this).setMessage(fileMessage);
3 ответа
Один из моих проектов похож:
- Sln
- Sln. Ядро
- Sln. Ядро. Тест
- Sln. Данные
- Sln. Данные. Тест
- Sln. Сеть
- Sln. Сеть. Тест
Ядро является моделью предметной области и доменными сервисами, насколько они могут быть сделаны, не ступая в персистентность. Данные являются слоем персистентности, который в основном означает определения FluentNHibernate и конкретные реализации интерфейсов, определенных в Ядре. Сеть является слоем фронтенда.
Я сделал нечто похожее на правосудие. Но с меньшим количеством проектов (и более быстрым временем компиляции)
Sln
- Project.Core
- Project.Web
- Project.Test
Project.Core будет выглядеть так
- Репозиторий
- Домен
- Presenter
- Сервис
- Просмотр
- Общий
Я не получаю выгоды от нескольких (более 3) проектов. Вы не получаете тестируемости, и время компиляции становится намного больше.
Кроме того, первое, что я делаю, когда получаю проект веб-сайта, это преобразовываю его в веб-приложение. Но в целом мои проекты не меняются, когда я переключаюсь между веб-сайтами и веб-приложениями.
Я обычно использую название приложения для названия решения (использующий универсальный тип проекта "Решения"), затем имею SolutionName. Сайт, SolutionName. Домен, SolutionName. Персистентность, и т.д.... для проектов это содержит. Это, кажется, помогает иметь дело со всеми ссылками.
Я хотел бы видеть другие ответы народов все же. В то время как это - лучший способ, я нашел, что не могу встряхнуть чувство, что мог бы быть лучший.