Pull to refresh

Comments 9

Могу еще порекомендовать глянуть тут Orchard2
А за статью спасибо. То же сейчас исследую этот вопрос.
Как по мне, так интерфейс(ы) доступа к данным должно реализовать основное приложение (ядро), а расширение уже должно использовать его. Но если хочется логику работы данных отделить, то да, нужно выделить специальный тип расширений — Data Providers. Хотя по сути оно будет одно — как у вас и вышло. Поэтому скорее это не расширение, а просто отдельная либа, которая реализует логику доступа к данным, и которую достаточно загрузить статически, вместе с запуском ядра.

Вообще для реализации системы расширений (плагинов) в .NET есть такая штука, как MEF2 (Microsoft.Composition).
MEF для веба мало интересен. Особенно в контексте vNext. Тут можно налету код плагинов компилировать при желании, плюс есть встроенный IoC контейнер. Имхо MEF удел десктопных приложений типа Visual Studio.
Я считаю, что неправильно складывать и контроллеры, и классы, взаимодействующие с хранилищем, в один проект. В крупном проекте это приведет к путанице и значительно усложнит командную работу. Также мне нравится, что даже если на самом низком уровне нет поддержки определенного хранилища, можно легко ее добавить, взяв за основу (в нашем упрощенном случае) AspNet5ModularApp.Data.EF.Sqlite и просто добавив еще один проект, не затрагивая ничего больше. (Например, в Платформусе я использую и SQLite, и MS SQL Server.)

Согласен, что работа с данными это часть функций ядра приложения. По сути, AspNet5ModularApp.Models.Abstractions, AspNet5ModularApp.Data.Abstractions и AspNet5ModularApp.Data.EF.Sqlite и есть частью ядра, которую используют все расширения, которым необходима работа с данными.

Что касается MEF – мне очень понравилась эта штука, я как раз построил предыдущий Платформус на ее базе. В новой версии использовать ее не стал. Насколько я понял, она не поддерживает dnxcore50 (по крайней мере, не поддерживала на тот момент, когда я с этим разбирался), а для меня это крайне важно. Кроме того, в ASP.NET 5 уже встроен DI, работать с которым удобно.
System.ComponentModel.Composition.* which has shipped with .NET 4.0 and higher and Silverlight 4. This provides the standard extension model that has been used in Visual Studio.
System.Compostion.*_ is a lightweight version of MEF, which has been optimized for static composition scenarios and provides faster compositions. It is also the only version of MEF that is as a portable class library and can be used on phone, store, desktop and web applications.

Кроме того, MEF — это не типичный IoC-контейнер. Некоторые IoC-контейнеры даже интегрируются с MEF (Autofac, Unity). Кто-то успешно юзает MEF для реализации системы, подобной той, что описывает автор статьи. Да, в контексте ASP NET 5 не пробовал, не знаю. Вот попробую и расскажу.
По сути, MEF делает за вас поиск сборок, извлечение из них типов и создание экземпляров объектов, поэтому это действительно больше, чем просто DI. Но все-таки для создания модульного веб-приложения этого недостаточно. Необходимо определиться, как подключать контроллеры и представления, как работать с данными и так далее. Так что это всего лишь инструмент, а не решение. Думаю, если задействовать его (MEF) в нашем тестовом примере, он не слишком изменится архитектурно.
Если бы вы заглянули в код, то поняли бы что MEF для vNext бесполезен, так как вы оперируете не только сборками, а еще и пакетами, причем пакет может быть в виде исходного кода, тогда на него можно натравить Рослин. Бриджи делаются по определенным причинам. И для веба по большей части не нужны(ну кроме случаев когда кто то решил нарисовать весь свой код на MEF И прибил это гврздями). Ну и статическая композиция тут ни к месту :)

Так как мы говорим именно в контексте vNext — то вот что предлагается использовать авторами.
А по вашей ссылке на DNF:
MEF can be used for third-party plugin extensibility, or it can bring the benefits of a loosely-coupled plugin-like architecture to regular applications.
Этот «успешный пример» кстати тихий ужас:
[Export("Plugin1", typeof(IController))]
[PartCreationPolicy(CreationPolicy.NonShared)]


В каждом контроллере такое прописать?
А как быть с Unit of Work?

Если брать текущий стек то вот здесь на Autofac просто неистовая магия сделана. Особенно в плане модульности.
Sign up to leave a comment.

Articles