I know this sounds lame, but MSDN seems to have a bunch of empty information on it. Like this link ServiceLocator. I just rolled onto a project with Unity and Prism. I have found it in some code where a WPF UserControl is passed in like this
var alert = ServiceLocator.Current.GetInstance<AlertControl>();
Is this like Unity's resolve?
http://commonservicelocator.codeplex.com/
From the project description:
The Common Service Locator library contains a shared interface for service location which application and framework developers can reference. The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.
This abstraction is implemented by several IoC frameworks out there, and Unity is one of them. nevertheless, Unity is not the owner of that project.
This way StructureMap, for example, provides implementation of those clases, so other frameworks (such as Prism from patterns & practices) can easily work with other IoC frameworks and not be bound to Unity itself.
Related
I am building an application using WPF, MVVM, and PRISM. the application is an intensive CRUD app, and the db is accessed using entity framework. i want to build the application using modules but i can't figure out where to put the data access code (more accurately i can't figure out where to put the repository interface) . if they go into an infrastructure project. then all modules will depend on that and it doesn't seem like the right place. on the other hand if the interfaces go into their respective modules then there will be lots of inter-dependencies between the modules which is bad.
Question: best way of designing a database-aware modular PRISM MVVM application and perhaps the best solution to my case ?
I think you may take a look at MEF. It allows you to have the level of abstraction and modularity you will need for this while everything working together in a seamless way.
I would recommend you to read official Prism guide.
I use this separation:
MyApp - shell project
MyApp.Infrastructure - all shared interfaces - including your IRepository
MyApp.DAL - contains all DAL classes, and also Repository implementation
MyApp.Modules.SimpleModule
MyApp.Modules.AnotherModel
etc.
Main thing about modules - they should not depend on each other, but they could depend on shared modules (e.g. MyApp.Infrastructure).
I need to write an application which can load plugins. I read the PRISM 4 documentation and i like the "Region" concept of the framework. But all modules are loaded in the first AppDomain - but i need to build an application where 3rd party plugins can crash without crashing the whole app (so i think multiple app domains are the best solution?)
Has anybody some experience with that topic? Should i build it on top of MVVM light myself? Is PRISM 4 the tool I'm looking for?
Thanks and best regards
To the best of my knowledge, none of the popular MVVM frameworks (Prism, Caliburn, Calcium etc.) support cross-appdomain module lifecycle and, just as importantly, cross-appdomain messaging out of the box. This said, it's not impossible to customise any of them to:
allow for modules to be loaded in different appdomains, perhaps based
on some configuration option;
create a remoting proxy for their messaging components (eg. event aggregator in Prism) so that a message is serialised into a different appdomain.
For one, Prism4 allows for multiple extensibility points on its bootstrapper, module catalog and service locator components, so loading DLLs and initalising their entry points on different appdomain is not too hard. Creating a remoting proxy of the event aggregator is a bit more complex.
I have personally resorted to creating a different message broker that works cross-process as well as within the same appdomain, however I had to write it from scratch.
I'm confused about the architectures which we can use to develop a business application with WPF 4.0 and EF 4.0 technologies.
My first choice was a traditional N-tier architecture contains: UI, Business Logic Layer & Data Access Layer with a disconnected behavior.
In this way I create 3 project for each layer and another project for my Entities/DTOs (Each layer is an assembly). Each layer references only to it's upper and lower layers (That is: UI can see the BLL but can't see the DAL). But all layers have access to the Entity/DTOs assembly for communication purposes.
The problem starts when I want to create a simple CRUD form with a DataGrid for example. The BLL disposes the DataContext of the DAL when returns an Entity/DTO, this is the reason that forced me to use STEs. But yet there are several problems. For example I should call "StartTracking" method for each entity returned from BLL to the UI. In short, I don't sure about this pattern reliability or I think I have to forget about automatic handled CRUD forms.
I use the repository model in my DAL layer but when I search about the repository pattern I find it different. It seems that it's not bad to reference to both of the DAL/Repository and the BLL/Services(Not WCF nor WebServices) layers from the UI and thus we can have a connected environment (Without using STEs).
I see an example in which we can get a person from repository but do something on it using BLL or services:
UI CODE:
var person = new PersonRepository().GetPerson(10);
Bll.Salary.PaySalary(person);
-or-
var person = new PersonRepository().GetPerson(10);
Bll.Person.MarkAsAbsent(person);
Or something like that...
With this pattern we can send the Entities/DTOs to the UI in a connected way while the DataContext is alive.
I don't know if I understand the way of using the repository pattern in big projects. I think it's not clear to naming the BLL or services classes and methods in this way. More over the developers might be confused about where to use the repository methods or BLL/service methods or about where to create the methods (in repositories or BLL/service).
I prefer the N-Tier architecture using a good approach to track the Entities/DTOs changes automatically like STEs.
Would you please recommend the best pattern in such situations or/and reference me to some good books or documents about that.
I put together a sample app that may help with some of your questions. You can review the presentation notes and the sample via my blog post here:
http://blog.alner.net/archive/0001/01/01/wpf_ef_4_sig_presentation_2010.aspx
The sample shows using STEs and includes some helpers to make the Entity Framework STEs work better in a desktop client app.
Repositories are there to hide the details of how you get the data. The idea is that you could swap the implementation of a repository from one that uses a local database, to one that uses a remote web service without the upper layers knowing about it.
Maybe the article Architecture for WPF applications is any help for you.
You might have a look at the BookLibrary sample application of the WPF Application Framework (WAF) as well. It shows a WPF MVVM application together with the Entity Framework applying the described architecture.
There seems to have a buzz around the Lightswitch application framework.
Reading some posts/forums/articles and listening to a video provdided some answers, but raised some others.
Extensibility?
Is there several hooks to override or extend features?
Modularity? Can MEF/Prism be integrated? Is there a concept of dynamic modules that can be loaded at runtime?
Localizable? Any special features about localization in different languages?
Versionnable? Any concept of version so simultaneous version can co-exist?
Abstraction? The connection to data source can be abstracted and replaced?
Testability? Are the different components unit testable in an automated way? Easy or difficult to achieve?
Cross-cutting / NFR ? Any hooks so we can plug NFR code? (logging, caching, audit, secuity )
Is this a solid framework to build some PAAS application over?
Let me give you my 2 cents based on an eval I just did:
Extensibility
You can of course add custom controls and apparently there will be a published extensability API.
Modularity
No. Lightswitch is not a code generator, it abstracts out implementation of the UI.
Localizable
Did not see anything, but I imagine this will occur in stages.
Versionnable?
You could TFS the Lightswitch project, but if you mean versioning from an execution standpoint ... it's as simple as deploying a new version of the app to the server. The client will check for updates on run and install as necessary from what I understand.
Abstraction
Yes, if you abstract it at the WCF RIA Services layer which is very easy to do.
Testability
Business rules can be implemented at the RIA Services layer so testing there should be a snap, but if you rely heavily on rules driven through the UI you will have to use another UI-based testing tool.
Cross-cutting / NFR
If you focus on getting the RIA Services tier of the app to be the central location for business rules and let the UI just focus on user experience you won't run into much overlap. I think Lightswitch is a good client for many solutions, but the core power of it is using it as a client for RIA Services which itself is not dependent on Lightswitch by any stretch.
I hope I at least provided some useful insight.
Extensibility? When the built-in LS controls don't allow you to do what you need, you can use just about any Silverlight control (including 3rd party controls), or create your own custom Silverlight controls. There is a little more work to do than using LS controls, because the LS controls have some extra "smarts" built into them, so you can just drop them on a screen, bind, & use them. There are also extensibility points built into the framework that allows you to create your own "extensions" (shells, controls, themes etc).
Modularity? LS already uses MEF under the covers, so it's quite possible that it may be able to be leveraged further in the future. LS does generate code, but for itself, not for external consumption. There is an excellent article, however, by Microsoft's Eric Erhardt
http://blogs.msdn.com/b/lightswitch/archive/2011/04/08/how-do-i-display-a-chart-built-on-aggregated-data-eric-erhardt.aspx
that shows how to reuse the data model that LS constructs (in Eric's case, he uses it to create a RIA service that aggregates data for presentation in a chart control).
Localizable? I don't believe there are currently any built-in localisation features.
Versionable? For a web-based app, if the data schema didn't change, I don't see why you couldn't publish separate versions, but desktop (OOB) apps are click-once apps & are therefore governed by that technology.
Abstraction? If you were to create a RIA service for your data source, you could abstract away the implementation details.
Testability? Unfortunately, V1 was not written with "testability" in mind. If you extract out your business logic into Silverlight class libraries (for use on the client, or full .NET class libraries for use on the server), you can unit test that logic, but the code that you write in an LS application itself is not really unit-testable at this point in time.
I have two silverlight assemblies.
In assembly 1 I have implemented an interface ISnProvider.
In assembly 2 I have a concrete class which implements the ISnProvider.
I plan on having more assemblies which will contain different implementations of ISnProvider.
Assembly 1 has no reference to assembly 2.
When my silverlight app starts up, I want to resolve the ISnProvider interface using an IOC container. Ideally I won't have to recompile my app to use different providers. I don't want to hardcode 'assembly2.dll' in my assembly 1.
Which IOC container will allow me to dynamically load these assemblies using silverlight?
Thank you!
santiago
You might want to take a look at the Managed Extensibility Framework (MEF) from Microsoft. That will certainly support your scenario (example here) although it does unfortunately mean you need to use attributes (e.g. [Import] / [Export]) at various places in your code.
Autofac is available in a Silverlight version and I would certainly recommend it for general IOC usage with Silverlight but I've never tried to get it to dynamically load an assembly without a direct reference and I'm not sure if it will support that in Silverlight (I'd love to hear if anyone has accomplished this with Autofac)
You could also use a semi-manual approach - here's an example of loading an assembly dynamically in Silverlight without an IOC container, which may or may not be useful for you.