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).
Related
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.
I am attempting to document a WPF Prism application made up of multiple modules. This scenario begs for module documentation, but I'm not sure if there is a formalized way of doing this in UML, either as separate packages or something more generalized.
Usually, your documentation / design modeling methodology are determined by your company's Software Development Plan or Process. If your company doesn't have one, you may be well served to first define your design documentation process, independent of what fits best for Prism - particularly if you have applications that have been developed that are not reliant on Prism. In my experience, Prism, in and of itself, doesn't lend itself necessarily better or worse to any design modeling approach.
That aside, and with respect to UML specifically, Prism modules can usually be logically divided into packages or use cases quite easily. You've actually already done that when you divided your application into modules in the first place: each module is a loosely coupled, reasonably independent portion of your application.
For example, UI concern modules can often be grouped both according to use case and as separate packages. Take the StockTraderRI for example: the News, Position, and Watch modules lend themselves quite easily to separate use cases (View News, View Position, Add Stock to Watch, etc.) Obviously, these can also be represented easily as separate packages, complete with static class diagrams.
With business or data layer modules, such as Infrastructure or service oriented modules, the representation may be almost exclusively as package / class diagrams, with some use case realization diagrams (sequence, etc.) being used to illustrate communication coming from the UI to the services. Again, with the StockTraderRI application, the Market module and Infrastructure DLL seem to lend themselves to a more static approach.
Again, your approach to documentation and modeling of your application shouldn't be dictated by Prism, as any good modeling language will be able to accommodate Prism.
I downloaded Prism v4 and ran the installer. I went into the directory and ran the two following batch files:
Desktop only - Open Modularity With Mef QuickStart.bat
Desktop only - Open Modularity With Unity QuickStart.bat
When I compile these applications, I don't see any real difference. I've searched for MEF vs Unity and I've found some pros/cons, but nothing that specifically states whether one is "better" (and I know that is subjective) with use in Prism. I guess perhaps if I list my requirements someone can point me to the correct technologies to use (even if it's not Prism 4).
The application is to be written in WPF (NOT Silverlight).
The main application will be extremely thin.
The main application will use a Web Service to build the menu of the "apps/modules" a person has access to.
The "apps/modules" will be completely contained in other managed libraries.
The main application gets views and viewmodels by reflecting into these DLLs.
The main application should feed in services for logging, etc. into these "apps/modules".
For example:
A basic user might have the options of:
ViewOnly Address record
All items Address related are within Address.dll.
An advanced user might have the options of:
New Address record
Open Address record (update/delete)
Manage users
All items Address related are within Address.dll.
All items Manage related are within Admin.dll.
The app should not actually reference either of these DLLs, I plan to reflect into them so that if there are 100 different modules and a user only has access to 2 of them, only 2 of them are downloaded and used. Whereas a user that has access to 10 of them gets those 10.
I've already solved the downloading DLL via WebService. :)
None is "better": they are different things.
IMO your choice should be driven only by your requirements. Based on the requirements you posted here I would suggest you to use MEF, because you have modules contained in DLLs and the main app is unaware of modules to load. Those tasks are the reason that why MEF exists.
Anyway you could use them both: MEF for modularity and Unity to take advantages of dependency injection (testability, reusability, ...)
If all the modules are not recompiled at the same time as the app, then MEF gives you lots of ways to cope with changing interfaces in the main app. Otherwise MEF may be more complex then you need.
I've been using Unity over a year with PRISM but I've noticed some serious memory leaking issues. Hence I decided to give PRISM 4 and MEF a go. What I've done is firstly converting my app to use PRISM 4 with Unity. Then I converted a branch to use MEF.
It may sound funny but MEF seems to handle memory consumption and release somehow better than Unity.
Would be nice to hear whether others have made the same experience?
Regard to your question whether MEF and UNITY can work nicely with each other, i can tell you that they are working really well with each other. I have developed a proof of concept application which used PRISM, Unity and MEF.
I am developing a silverlight application for the past 6 months using prism framework. When I look at the code base now it has grown huge with lots of modules, event aggregators, inter module communication code etc. On hindsight I am contemplating whether I made the right choice. Is there any other simpler framework I should have gone for ?
Prism is at its best when targeting a large application. Why? Because the core concepts Prism provides, such as Modularity, UI Composition, support for MVVM, etc. are used the most in this kind of applications.
The idea, as you said, is that you are likely to end up with a bunch of modules. The benefit of that is that your application is decoupled, and modules can be tested in absolute isolation so they are easy to maintain.
By using Prism, or any other library/framework that modularizes your application, (correctly) in large applications, you don't need to go through your entire application looking for bugs when you make a change to one of the parts. This is not true in monolithic applications, where making a minor change might bring down the entire app.
Another plus for Prism in this scenarios is that it allows multiple teams to work on different modules simultaneously, without affecting each other's work. This is specially useful when working with distributed teams.
The thing that would convince you of making the right choice, would be comparing the application you created with the same one but with high coupling of its components.
I hope this helps