To what extent, if any, is MEF a replacement for PRISM?
Today I would say Prism and MEF complement each other. Just as Prism and Unity. Prism introduces a set of specific services like RegionManager, DelegateCommand, and EventAggregator which aid in building composite apps. MEF on the other hand is a more general composition mechanism for extensibility of applications and frameworks whether they are composites or no. The key distinguisher about MEF is it's discoverability which means that it can go out and discover all the available parts dynamically.
You might be interested in checking out the MEF contrib project (mefcontrib.codeplex.com) which contains an integration layer for Unity and MEF. With that extension, Unity manages MEF behind the scenes, so you are not contending with two contianers. The advantage is it allows you to use Unity for general Pocos, and MEF for discovery of extensions. Thus as Prism is currently built on Unity, you can use it to leverage MEF. To use the contrib project, you'll have to make some slight changes to your Unity Bootstrapper, but it should be fairly trivial.
There is definitely some overlap. The place where it's the most prominent is with regard to modules. Prism uses an IModule as a means of discovery. In MEF, any component can be a part and can be dynamically discovered. This means with MEF you have modularity from top to bottom, wheras with Prism, modules are more granular units. Composite applications is definitely an area we are conerned with on the MEF time. Over time it is quite likely you will see more and more support for building those types of apps within MEF itself. We're working with p&p to ensure that as that happens, there is a smooth transition.
Edit: Do not read this answer. It is embarrassingly wrong. I am fail. Read Glenn Block's below.
It's not obvious, but this is the same question:
Managed Extensibility Framework (MEF) vs. Composite UI Application Block (CAB)
Consensus in the duplicate post is that MEF and Prism provide the same basic set of functionality in different ways, except that Prism provides the Event Aggregator, which is a pub-sub means of communication between application components. You can use this with MEF, however. It's pretty much up to preference, really.
Take a look at this Sparkling Client podcast on MEF and Prism.
MEF will never replace prism
MEF is a dependency injection manager.its not a dependency injection container.
MEF provides ability to assign exports and imports delclaritively using attributes.
Prism with MEF gives you ability to ability to auto discover dlls and ability to add and remove plugins by adding or deleting dlls.
Where as prism framework gives event aggregator, region manager, service locator.
You can use prism without MEF. There are various other options like ninject, unity and other DI containers.
You can use MEF with prism for building plugin based extensible applications.
Related
my question is easy, I think. In my solution, I used to create different projects, for example, one for data logic (layer), business logic, etc.
Now, I have to create a library not only for my projects but also an SDK for third parties. I'm not sure if I create a PCL library, my third parties can use it in shared projects. In this library, I have to call HttpClient and I should use Refit and Polly.
I read on Xamarin Help that Portable Class are obsolete. Really?
Any advice? Thank you in advance.
PCL were superseded by SCL (.Net Standard) projects.
You can upgrade your existing projects, as described here
For the new projects, just use .Net Standard
When creating a new app in Xamarin Forms I see these two options:
Configure your Forms App
Shared Code:
Use .NET Standard
Use Shared Library
Can someone explain the difference? I looked at the help and I am still confused. I'd appreciate if someone can give me any advice on this. Not sure if it helps but this app is self contained and no code in the app will need to be shared with any other application.
In terms of what you can achieve with both, it is the same. So, in the end, it's mostly a matter of taste.
The biggest difference is that a shared project is compiled into the app itself. It is nothing more than it says on the tin: it's a shared folder that you can use in all platform projects. Using platform-specific code is done through compiler directives.
With a .NET Standard project, you will get a physical binary. It is a project of its own. You can reuse it in other .NET Standard projects, although you already mentioned you won't be using it for that. Executing platform-specific code requires a bit different approach, using the DependencyService.
Seeing that they made a choice to replace the PCL with .NET Standard but keep the shared project points out that the shared project is here to stay for a while. I tend to like the .NET Standard library more. It feels cleaner and forces you to write cleaner code. Also, .NET Standard isn't going anywhere soon and if you decide that code should be reused down the road, you have the ability to.
A good overview, together with pros and cons can be found in the Microsoft Docs: https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing
I have small problem - I'm trying to implement class that needs to contain a lot of events. Due to memory concerns I planned to implement EventHandlerList which is available for me in my Android Library project target also in my iOS Library project target but is not available for me inside PCL Project. Tried to change PCL Target project to most commonly used but none of them contained what i needed.
Type missing for my case :
System.ComponentModel.EventHandlerList
Is there any possibility to write such class once or I'm forced to write it two times because of missing PCL Target.
You will need Inversion Of Control (IoC) to use platform specific features or non-portable methods
Please take a look at this IoC example
Another option if you want to avoid IoC is to use Shared Project in Xamarin
I'm building a project that includes an MVC Web Api hosted in Azure and an iOS app. I'm trying to use Xamarin to build the app. As I understand it, I should use a portable class library in my Xamarin project to allow me to share the code between my Web Api project and the Xamarin app, as well as any future apps on other platforms like android.
So right off the bat I would want to put my models in the portable library. The app and the web api will pass those models back and forth. But the portable library doesn't have the Azure Table Storage library. It doesn't even have some very basic stuff. My models need to reference the Azure Storage Library so I can save instances to storage.
What is the best way to make this code shareable? Obviously I need to duplicate my model classes so they can exist in each location. But should those in the PCL inherit from those in the Web Api project? Vice versa? Should there be an interface that both inherit from (actually the Azure Table Storage library requires the classes to inherit from ITableEntity already...). Just looking for the best way to share these classes between the Web Api project and the PCL used by the Xamarin project.
Using a PCL - Portable Class Library is a great way to get started! There are a few quirks that you may want to understand prior to sharing your code.
The PCL Profile is a limited set of APIs available. Meaning that certain classes/assemblies might not be included. You can typically look up the class/assembly via MSDN and see if it has a PCL icon next to the class name.
If the library you are trying to use has assemblies not inside the current PCL Profile but can be found on the native platforms, you will want to use the IoC/DI pattern.
Hopefully the library you're using supports PCL. Otherwise, you will need a library that does support the PCL Profile. (You can check this by downloading the .nupkg, extracting, and looking at the libs folder). Note: You may want to check the Prerelease NuGet channel for PCL support. Sometimes you can find an open source project and remove/replace certain assemblies/code to make it Portable.
General Guidelines:
Keep your POCO classes simple in the PCL. If you have platform specific quirks you need to add to the models, make a Model layer on that platform that inherits from your simple PCL models. EX: Your Web API has a specific [Attribute] tag or interface that you need to apply to your model. You might already have a Model such as Person which is a simple POCO class in your PCL, and then you can create a PersonApiEntity model which might inherit Person and any platform-specific APIs you need to apply to it.
It seems ITableEntity/TableEntity is not supported in the PCL Profile.
https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storage.table.itableentity.aspx
Seeing the source at a quick glance(https://github.com/Azure/azure-storage-net/blob/master/Lib/Common/Table/ITableEntity.cs)
I have the following requirement.
I need to implement dll kind of thing on mac.I need to create a backend library which can be loaded dynamically.This backend library will contain the cocoa classes and c++ classes.
What is advantage/disadvantage of cocoa framework,I was googling so far,I was not able to figure out the best one.Please give me some suggestion.Is cocoa framework also loaded dynamically?
The main difference between a dynamic library and a framework is that a framework can contain resources (images, sound files, nibs, etcetera) and header files. When you use a dynamic library, these are separate.
Both a framework and a dynamic library are loaded at runtime. If your library will only be used on Mac OS X, I recommend creating a framework because it is easier to manage since everything is in one folder.
Bundles (the white LEGO bricks) are almost exclusively used as plug-ins. If you want to create a plug-in interface you should accept bundles and you should provide a framework the bundles can link against. Bundles are also loaded at runtime.
Here's a decent tutorial (PDF form) that goes a little more in depth explaining the differences between ordinary libraries and frameworks.