UnitOfWork и разделение ответственности?

Я использую дизайн UnitOfWork/Service Layer/Repository/EF4 w/POCO в своем приложении MVC.

Пока у меня это:

1) Веб-приложение MVC (Project.dll)
2) Уровень службы (Project.Data.Services.dll)
3) Уровень репозитория (Project.Data.Repositories.dll)
4) POCOS (Project .Data.Domain.dll)
5) EF4/контекстный уровень (Project.Data.dll)

Каждый уровень ссылается только на нижний уровень и Project.Data.Domain (классы POCO).

В настоящее время у меня есть интерфейс/база UnitOfWork в Project.Data.dll, но теперь все слои должны ссылаться на него. Это плохой дизайн? И если да, то где он живет?


repository-pattern asp.net-mvc-3 unit-of-work entity-framework-4 service-layer
person Sam    schedule 03.03.2011    source источник

Ответы (4)


arrow_upward
2
arrow_downward

Это просто мнение.

Объекты домена являются частью бизнеса. То же самое для контекстов и репозиториев.

На самом деле я хочу сказать, что OR/M — это абстракция над реляционной базой данных или другими типами хранилищ, поэтому они могут действовать как объектно-ориентированное хранилище.

Это OR/M отбрасывает уровни данных в современных программных решениях.

Репозитории, контекст домена, объекты домена являются частью бизнес-уровня.

Единица работы — это шаблон проектирования программного обеспечения, и он предназначен не только для работы с базами данных или уровнем данных, но и для управления другими вещами, такими как сетевая транзакция. Я бы предложил включить это в какое-то пространство имен, например «YourCompany.YourProject.Patterns.UnitOfWork» или что-то в этом роде.

Сервис не имеет ничего общего с данными. Я хотел бы предложить пространство имен "YourCompany.YourProject.Services".

Еще один момент заключается в том, что ваши POCO, по-видимому, тоже работают как DTO, потому что вы используете их везде, даже для передачи данных через слои и/или уровни. Это может быть нормально в реализации «голых» объектов или чего-то в этом роде, но вам нужно обратить внимание на факт использования объектов домена в качестве DTO, потому что они могут содержать свойства, информацию, поведение или OR/M, проксирующие скрытые члены, которые могут влияет на вес объектов - использование памяти -.

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

DTO, реализации шаблонов и подобные вещи, общие для всех проектов, часть вашего решения должна жить в каком-то проекте под названием «YourProject.Shared», и эта сборка не должна ссылаться ни на какой уровень: она должна оставаться нейтральной по отношению к уровню, поэтому ссылайтесь на нее везде не заставляет иметь бесполезные зависимости.

Ну, это мое мнение и способ работы в моих проектах.

person Matías Fidemraizer    schedule 03.03.2011
comment
@Mat - я использую модели просмотра / редактирования в своем приложении MVC, а затем использую AutoMapper для сопоставления pocos с моделями. - person Sam; 03.03.2011
comment
Что ж, я ответил вам информацией, которую вы сказали в своем вопросе! :D В любом случае, я просто объяснил это, чтобы дать вам правильное направление в именовании, потому что даже если вы используете AutoMapper или что-то еще, имеет смысл называть вещи правильными именами, чтобы исходный код был более читабельным или, по крайней мере, вещи были найдены в нужных местах. - person Matías Fidemraizer; 03.03.2011
comment
@Mat - Значит, вы не думаете, что репозитории и ниже - это уровень данных? Я точно соглашусь, что POCO - это бизнес-объекты, но я думаю, что репозитории и ef - это данные. Нет? - person Sam; 03.03.2011
comment
Репозитории — это не данные. Репозиторий — это сущность, отвечающая за преобразование бизнеса в данные и данных в бизнес, и работающая как набор объектов. И сам по себе EF — это не данные, это OR/M, который является абстракцией реляционных данных с интерфейсом ООП, поэтому неясно, что DataContext будет уровнем данных, поскольку на самом деле это единица работы Entity Framework. Данные будут представлять собой некоторый уровень реализации Entity Framework, отвлеченный от вашего бизнеса. - person Matías Fidemraizer; 03.03.2011
comment
В любом случае, возможно, есть другие мнения по этому поводу, просто подождите других ответов и сравните, прочитайте документацию, и вы сможете сделать хороший вывод! :) - person Matías Fidemraizer; 03.03.2011
comment
@Mat - я уважаю твое мнение. Спасибо!! - person Sam; 03.03.2011

arrow_upward
2
arrow_downward

Я думаю, лучше, если вы используете внедрение зависимостей. Вы можете взглянуть на этот замечательный пост: http://blog.keithpatton.com/2009/05/30/Entity+Framework+POCO+Repository+Using+Visual+Studio+2010+Net+40+Beta+1.aspx

person Kalman Speier    schedule 03.03.2011

arrow_upward
1
arrow_downward

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

person Ladislav Mrnka    schedule 03.03.2011

arrow_upward
1
arrow_downward

Взгляните на https://github.com/sharparchitecture/Sharp-Architecture, там есть Northwind пример, который многоуровневый, как ваш. Вы увидите реализацию UnitOfWork.

person ruslander    schedule 03.03.2011