.NET многоуровневый дизайн LINQ

Question

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

Это традиционное трехуровневое приложение, которое содержит: DataLayer (LINQ + частичные классы) BusinessLogicLayer (Entities + Validation Logic) (необязательно) UI сервисного уровня (WCF) (веб-сайт иПриложение для Windows)

Уровень данных: уровень данных будет содержать мои классы DataContext (т.е. LINQ) и частичные классы.Эти частичные классы будут иметь базовую логику расчета (например, Calc. VAT) и другую логику проверки на уровне базы данных.

Бизнес-уровень: в нем будут вводы, аналогичные уровню данных, но также они будут содержать логику проверки на уровне пользовательского интерфейса.Например, если пользователь пытается ввести имя пользователя, которого нет в базе данных, он должен сообщить пользователю, что пользователя не существует.(это место, где я борюсь).Объект будет Lazy Loaded всякий раз, когда будут вызываться свойства, а не при создании объекта.

UI: это будет традиционный уровень пользовательского интерфейса, к которому будут вызываться бизнес-объекты.

Причинапочему я освобождаю бизнес-уровень от DataLayer даже при использовании LINQ, потому что если я хочу добавить больше объектов среднего уровня, например, для службы WCF, то я хочу, чтобы он взаимодействовал с бизнес-уровнем, а не с данными.Я верю, что разделение помогает, когда приложение растет. (Я думаю)

Я бы оценил, если бы кто-то мог прокомментировать вышеприведенные строки.Моя настоящая проблема - написание бизнес-классов (очевидно).Например, при отложенной загрузке, когда я пытаюсь загрузить объект, а в базе данных нет данных, я хочу, чтобы мой пользовательский интерфейс показывал пользователю, что пользователь не существует (если я ищу имя пользователя).Каковы ваши рекомендации относительно этого.Любой вклад в это очень ценится.

Большое спасибо, Preyash

Answer 1

Один совет здесь - следовать парадигмам KISS / YAGNI.Не обязательно погружаться в сложную архитектуру только потому, что вы думаете, что она понадобится вам позже, когда ваше приложение будет расти.

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

Относительно васвопрос об интерфейсе пользователя, это хороший пример того, как простота архитектуры упрощает все остальное.Простой способ загрузить пользователя, который возвращает ноль, если пользователь не существует, может быть легко интерпретирован вашим пользовательским интерфейсом.Но как только вы попадаете в сложные бизнес-объекты, вам нужно продумать гораздо больше последствий.Ваш пользовательский интерфейс становится тесно связанным со сложными бизнес-объектами, а не простым CRUD-интерфейсом для доступа к данным, поэтому вы можете сказать, что ваше приложение стало скорее связанным, чем меньшим.

Мой подход при создании приложений для клиентов обычно заключается в том, чтобымаксимально тонкий слой сервера.Сохраняя бизнес-логику с данными (т. Е. В базе данных) и логикой UI в UI (т. Е. На клиенте), все, что делает сервер, - это передает очень простые объекты данных между клиентом / сервером с помощью веб-служб.

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

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