Из того, что я вижу, у вас есть четыре пункта, которые необходимо решить:
(1) «Имея это в виду, я не уверен, что мне нужна полная архитектура уровня предприятия»
Давайте сначала разберемся с пухом высокого уровня. Это зависит от того, что вы подразумеваете под «полной архитектурой уровня предприятия», но краткий ответ «Да», вам нужно рассмотреть многие аспекты системы (и это будет зависеть от контекста системы относительно основных) , Если бы не что иное, ключевыми были бы Изменить и Поддерживаемость . Вам необходимо структурировать приложение таким образом, чтобы оно поддерживало изменения в будущем (логическое и физическое разделение интересов (Dependency Injection отлично подходит для последних); модульное проектирование и т. Д.).
(2) «Как правильно разделить проблемы в моей архитектуре без проектирования космического корабля?»
Мне нравится этот подход (это статья, которую я написал, которая переписала все, что я выучил до этого момента) - но вот суть:
Глядя на это, у вас будет минимум шесть сборок - и это не так уж и много. Если вы можете разбить свою систему (разделить задачи) на эти большие группы, это будет иметь большое значение для предоставления того, что вам нужно.
(3) Деталь
Разделение задач на разные слои и классы - это замечательно, но вам нужно пойти дальше, если вы хотите эффективно справляться с изменениями. Инверсия зависимости (DI) является ключевым инструментом для использования здесь. Когда я узнал DI, это было дело, созданное вручную (как показано в предыдущей ссылке), но сейчас для этого есть множество структур (и т. Д.). Если вы новичок в DI (и работаете в .Net), статья проведет вас через основы.
(4) Как двигаться вперед
Получите простой вертикальный срез (пользовательский интерфейс вплоть до БД), работающий с использованием DI и т. Д. При этом вы также будете строить основы платформы (подсистемы и основные системы), которые будет использовать ваша система. использовать.
После начала работы на втором срезе; именно в этот момент вы должны раскрыть все места, где вы случайно не используете вещи, которыми вы должны быть - это время, чтобы изменить их, прежде чем создавать срезы 3,4 и 5 - до того, как будет слишком много переделок.
Обновления для комментариев:
Как вы думаете, я должен полностью
удалить веб-формы и взять MVC из
царапина или просто с тем, что я знаю для
сейчас?
Понятия не имею, но для ответа «да» вам нужно будет ответить на следующие вопросы «да»:
- У нас есть необходимые навыки и опыт для использования и поддержки MVC.
- У нас есть время для внесения изменений (внесение изменений очевидно).
- Мы знаем, что MVC лучше подходит для наших нужд.
- Внесение этого изменения не ставит под угрозу успешную доставку.
... мне нужно перейти к проектам и
настроить каждый из этих слоев как
отдельный проект?
Да. Проекты сопоставляются со сборками 1-к-1, поэтому, чтобы получить преимущества слабой связи, вам наверняка захочется разделить вещи таким образом, и будьте осторожны при настройке ссылок.
когда вы ссылаетесь на POCO, подразумеваете ли вы просто DTO или объекты расширенного домена?
DTO не Rich Domain Object. НО люди, кажется, используют термины POCO и DTO взаимозаменяемо, если строго говоря, что они не являются - если вы из школы мысли Мартина Фаулера. По его мнению, DTO будет набором POCO (или других объектов (?)), Соединенных вместе для отправки «по проводам», так что вы сделаете только один вызов какой-либо внешней системе, а не много вызовов.
Все говорят, что я не должен выставлять свои
структуры данных для моего интерфейса, но я говорю
почему нет?
Управление зависимостями.То, что вы не хотите, чтобы ваш пользовательский интерфейс ссылался на физическую структуру данных, потому что, как только это изменится (и это произойдет), вы будете (если использовать технический термин) облажаться.В этом весь смысл наслоения.То, что вы хотите сделать, это чтобы пользовательский интерфейс зависел от абстракций , а не от реализаций.В 5-уровневой архитектуре POCO безопасно использовать для этого, потому что они являются абстрактным / логическим определением «некоторой вещи» (бизнес-концепции), и поэтому они должны изменяться только при наличии бизнес-причины - поэтому в этом смысле они довольно стабильны и безопаснее зависеть от .