2015-03-11 3 views
0

Итак, я пытаюсь научиться сохранять хорошую структуру в приложении WPF и нелегко определить лучший способ работы с BLL и DAL.Различные модели как в BLL, так и в DAL

У меня уже есть несколько моделей в моем УСКЕ, например:

клиента, счетов, и т.д.

Я также использую MVVMLight инструментарий, чтобы сделать вещи проще, так почти все мои модели наследуют из «ObservableObject».

Теперь я собираюсь создать DAL и использовать инфраструктуру Entity. Поскольку все мои модели используют ObservableObject, я чувствую, что не могу просто переместить их в свой DAL, чтобы создать мои таблицы (сначала код).

Будет ли лучший способ создать практически идентичные объекты в моем DAL и отобразить все данные на мои старые модели в моем BLL, когда я их получу? Я знаю, что это немного двойной работы и так, но не могу понять, как я могу держать его более чистым (кроме стоп наследоваться от ObservableObject)

+0

Для любых пользователей, не знакомых с выше сокращений, BLL означает * Business Logic Layer * и DAL означает * Доступ к данным слоя *. – Sheridan

+0

Обычно генерируемые объекты из DAL должны * не * использоваться в BLL и поэтому должны быть скопированы в объекты BLL. Обратите внимание, что ваши объекты в двух слоях не должны быть почти идентичными * ... ваши бизнес-объекты должны (или, по крайней мере, могут) быть иерархическими, в отличие от ваших объектов DAL. – Sheridan

+0

Я вижу, да, тогда я на правильном пути. У меня к этому короткий вопрос, есть ли для этого нормальное соглашение об именах? Я предполагаю, что «Клиент» как в DAL, так и в BLL может быть немного запутанным. Нормальный, чтобы иметь что-то вроде CustomerBll, CustomerDto? – user1776562

ответ

-1

Сущности как Customer и Account должны принадлежать к Domain модели. Рекомендуется сохранять агностик извсех неактуальных зависимостей, таких как MVVM-blablabla. Сначала я бы рассмотрел, как удалить зависимость от MVVMLightToolkit от ваших моделей. Вы всегда можете положиться на INotifyPropertyChanged, иногда лучше пожертвовать несколькими синтаксическими кусками sugare. Если вы можете избежать дублирования, вам следует избегать этого.

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

Рассмотрим изучить следующие материалы:
domain-driven-design-fundamentals
Eric Evans book on DDD

+0

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

+0

Это означает, что ваш домен тесно связан с инфраструктурой WPF. Часто это очень плохая идея. – EngineerSpock

Смежные вопросы