Архитектурная головоломка

Question

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

Пройдя по этому пути в течение некоторого времени, мне понадобится помощь сообщества.

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

Таким образом, основная идея состояла в том, что отдельные «репозитории» работают каждый в своей отдельной базе данных и что бизнес-уровень затем объединяет бизнес-объекты, которые затем преобразуются на уровне представления в объекты представления.

Основная проблема, с которой я сталкиваюсь, заключается в следующем:

Несколько классов для одной и той же концепции - Существует DAL-представление user и BL-представление user и представление представления пользователь . Я могу справиться с преобразованием с помощью инструмента, но действительно ли это правильный путь. Я имею в виду, что они все хорошо разделены, но накладные расходы - это нечто.

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

Answer 1

Честно говоря, я не вижу в этом проблемы. Наличие отдельных классов для данных в отдельных слоях означает, что вы можете изменить один без изменения других. Дополнительные затраты на другие представления обычно довольно минимальны - скорость печати, как правило, не влияет на производительность.

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

IOW, при необходимости распространять изменение по нескольким слоям может сосать, ему часто может помочь правильная оснастка и т. Д. С другой стороны, когда тривиальное изменение уровня данных имеет непредвиденные побочный эффект в вашем пользовательском интерфейсе, который всегда отстой, и замедляет любые изменения, поскольку все, что вы делаете, может сломать что-либо во всей системе.

Answer 2

Это больше, чем обычно.
Обычно никто этого не делает и плачет о проблемах с отложенной загрузкой ORM при рендеринге html или еще чего-нибудь.

Проще написать слой DTO, чем думать о DA, BLL и UI одновременно. Некоторые идут еще дальше и применяют разделение команд и запросов в архитектурном масштабе, четко рисуя границу между вводом / выводом (что решает такие проблемы, как потребность в искусственном бизнес-объекте, который фактически используется только для целей отчетности).

---

С другой стороны - это зависит. Если ваше приложение будет простым, вам может не понадобиться такая большая абстракция (например, простая домашняя страница портфолио компании).

Answer 3

Такова опасность наличия нескольких хранилищ. Это поднимает вопрос о том, «нужны ли они вам все или нет»? Имеет ли смысл объединить кого-либо из них, а можете?

Я бы посоветовал вам немного почитать об Архитектуре данных - я сам начинающий, но у меня есть кое-что от очень опытного. С одной точки зрения, архитекторов данных больше беспокоит то, как определяются ваши данные, чем то, как фактически создается физическая база данных: мой совет - начать с захвата и документирования ( моделирование ) логической модели данных, и физические. Очень четкое понимание данных очень поможет.

Специфика этого (то есть, биты, о которых беспокоится DA) - это определение данных - что это за бит данных (не полагайтесь на имена столбцов и таблиц)? Как это используется, что это означает, где это создано? Также важно то, что речь идет не о том, где он физически создан в вашей системе, а о том, где он создается в бизнес-процессе (ах). да, вам нужно беспокоиться о системе - но это на потом; бизнес процесс должен управлять системой. Это все логические модели данных.

Как только у вас есть определения, вы можете начать собирать их вместе - как соотносятся данные из разных репозиториев? (возможно, больше в физической модели здесь.)

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