Альтернатива Asp.net MVC с репозиториями

Question

Альтернатива Asp.net MVC с репозиториями

1

По-видимому, существует множество руководств, которые подталкивают использование Entity Framework с шаблонами репозитория и единицы работы при разработке проектов ASP.Net MVC.

Быстрый Google дает бесчисленные дискуссии о Pro и минусах этого подхода, и пока те, кто выступает против использования этих шаблонов с EF, вокалируют, я еще не видел, чтобы кто-нибудь детализировал хорошую альтернативу.

Не имея прямого доступа к EF в классах контроллера, какой другой подход к уровню доступа к данным?

Jacob 26 авг. 2014, в 13:45

Источник

0

Я для себя использую TortoiseHG tortoisehg.bitbucket.org Я надеюсь, что это то, что вы ищете.
Fabian Harmsen 26 авг. 2014, в 11:07
0

@FabianHarmsen Он говорит о шаблоне дизайна репозитория. Не исходные репозитории
Charanraj Golla 20 сен. 2014, в 16:48

Теги:

c#

entity-framework

asp.net-mvc

repository

1 ответ

Ещё вопросы

Я для себя использую TortoiseHG tortoisehg.bitbucket.org Я надеюсь, что это то, что вы ищете.
@FabianHarmsen Он говорит о шаблоне дизайна репозитория. Не исходные репозитории

Jason Evans · Answer 1 · 2014-08-26T09-34-00.000Z

Раньше я использовал репозитории; Я думал, что они были лучше всего после нарезанного хлеба.

Однако со временем и с приобретением опыта я прекратил использовать шаблон репозитория. Мои классы репо неизбежно заканчивались тем, что были забиты множеством методов, многие из которых почти передразнили сохраненные процессы e..g

customerRepo.GetCustomerWithFooBar();

sp_GetCustomerWithFooBar

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

Контекст Entity Framework Я просто закодирован против самого объекта контекста; запуская запросы LINQ, а также обычные вещи SaveChanges().

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

CQS (разделение командной строки) Идея состоит в том, чтобы иметь классы команд do и других классов, которые выполняют запрос. например

public class SaveCustomerCommand() {}

public class ListCustomerQuery() {}

Таким образом, я смог красиво абстрагировать свой код Entity Framework на две категории - те классы, которые меняли данные, и те, которые просто читали его. К сожалению, я никогда не заканчивал код, где я экспериментировал с этим подходом, но вы могли бы рассмотреть вопрос о создании класса CommandDispatcher который принимает в себя команду/запрос, новый объект UnitOfWork (как бы вы это не реализовали) и управляйте командой.Execute() и query. Execute().

Есть статьи, которые могут помочь вам встать и работать с помощью метода 2.

http://alertcoding.wordpress.com/2013/03/17/command-and-query-based-entity-framework-architecture/