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
Related
I need to write a composite WPF application with parts being potentially developed by other teams. These parts are actually indepndent applications now, and we want to put them under common "roof".
Two main options I consider for composition is Prism modules vs. MEF parts, and I am not 100% sure which to choose, since both have pros and cons. Note, that this is NOT about the IoC container choice, this is about discovering pluggable components. I am pretty much settled on the opinion that MEF is not to be used as an IoC container.
If I go with MEF for pluggability, the biggest plus is that it is baked in into the .NET framework, so there are no versioning issues. From the other hand, I will have to (partialy) reinvent mechanisms such as Prism region managers and other UI composition features.
If I go with Prism modules, I get much richer integration functionality (regions, event aggregator, etc.), but for that to work everyone must be on the same version of Prism, and preferrably the same version of Unity, to avoid unpleasant surprises. Upgrading to a next version of Prism/Unity will thus become a challenge.
I would like to hear your opinion about the choice.
I had a similar choice several years ago and choose Prism. I'm glad that I did. Unless I was building a trivial app, I wouldn't consider doing it without Prism. You can have different dev groups work in near isolation on their modules and integrate them when complete. The same goes for bugs and requirement changes: much easier to handle.
Yes, you'll want everyone working on the same version, but that's a small price to pay and very common. If you have specific questions, let me know.
Seeing as how MVVM is being highly regarded as a good system design pattern, I thought I might just jump aboard and give MVVM a shot.
Just a little background about myself before I begin with questions:
I have done a few years of development with ASP.NET Webforms. I have also done a fair bit of development in ASP.NET MVC, which I am quite comfortable with.
Currently, we have a number of "backbone" applications written using ASP.NET MVC 3 which we customize and sell to our clients whenever we're approached. These applications are all meant for internal use, hence plug-ins wouldn't be much of a problem.
The real problem with development is that for large scale business applications with complex business rules, ASP.NET MVC tends to slow us down (writing jQuery / javascript > server side processing > return result, use jQuery to notify > alter view, something along this line).
Then I began looking for answers that will help us improve our time to delivery and also responsiveness (well, we all know how JavaScript is capable of killing us) and my search brought me to Silverlight (we have the time to change, no worries there).
So here comes the questions:
I have come across many Silverlight MVVM samples online, but all of them show applications as simple as interacting with only one Database table. Is MVVM pattern well suited for large applications?
In MVC, I'm used to Dependency Injection from Ninject to pass an implementation of UnitOfWork to my Controller. In all samples I found online, none of them use any form of DI. Is it really unnecessary? Since the idea of MVVM is to decouple, so why not also decouple ViewModel from Model?
I've gone through a book published by Jeremy Likness called Designing Silverlight Business Applications. He used MEF to do the decoupling, which I think doesn't really fit into our application. We do not really need to do "hot-plugging". What's your take on this?
MVVM is all about Commands, Databindings and No Code-behinds. What if I want to interact with UIs that do not expose to commands? (I'm not too sure about this, I'm guessing ListView OnSelectionChange?)
To add to the previous answer:
We are developing a large corporate-wide Silverlight platform and a set of applications using MVVM. Seems to be working pretty well.
We are using DI extensively. Our system is built on top of Prism. Prism contains a large amount of sample applications of various complexity illustrating the use of DI in MVVM.
We use Unity as our IoC container. Prism contains guidance for both MEF and Unity. Unity seems to be a more traditional IoC approach.
In the vast majority of cases using Bindings and Commands covered our needs. For the others we use Expression Triggers and Actions. You can also create custom Triggers/Actions if necessary.
I have no answers for all your answers (never used MEF) but I can tell you my experience:
1- I've been in the development of a quite-large silverlight application and MVVM fits perfect to have a maintainable application. The bigger problems we had because of application size were because of Silverlight, not MVVM 8-)
2- I haven't used it too much but it's useful in many cases. There are several toolkits to use DI with Silverlight like MVVM Light Toolkit:
http://compiledexperience.com/blog/posts/blendable-mvvm-dependency-injection-and-unit-testing
4- For interaction between UIs you can use the Mediator pattern. The same MVVM Light Toolkit has a Messenger to subscribe, send and receive messages and maitain every layer decoupled.
Hope this helps you ;-)
I am currently working on a project of mine using Prism (the Composite Application Library/Guidance). The application will be a specialized MSPaint-like application for basketball (predefined objects for balls, players etc.).
Now I am wondering how to go about organizing my application into Prism modules. Especially when thinking about the drawing part of the software.
Should I split the general drawing view (2 columns: toolbox, canvas) in 2 modules (toolbox and canvas) or would the overhead created by the constant communication of these modules be too overwhelming?
How fine grained should Prism modules really be?
Thanks in advance and best regards,
crischu
There's very little overhead when you separate into modules.
I would go with what helps you organize your solution, rather than worrying very much about performance considerations. You can easily combine modules if you find they are causing you trouble or you are finding that two modules really belong together.
The rule is:
Make it run.
Make it run right.
Make it run fast.
In that order. Do what feels good first and refactor later if necessary.
I'd say it depends on how you distribute the functionality of your application over the UI. If you have just one screen, but with multiple sections that manage different features, each of that section (tab page, panel, etc) should have it's own module. This is the case with the StockTrader RI or NewsAggregator samples.
But on the project we are starting we decided to have multiple pages, one page for each major feature and to have navigation between them. In this case, a module will represent a page, nothing smaller than that.
We are developing/mantaining an enterprise application which for historical reasons and development speedup it was targered for WinForms.
Now we are thinking that sooner or later (more sooner than later) that application will need to be Web based.
Thinking on the "to-Web" movement. Which are the most important things we have to consider? Something like, thing on MVP parading (or others), determine now the kind of platform/framework you are going to use, ...
Any experience on migration from winforms to web? Any suggestion to take care?
Aclaration: In our scenario the application would be nice NOW to be Web based but we are realistics. I agree that not all the applications have to be Web based (this is the main reason we developed with WinForms!). But sometimes the requirements changes and, in our scenario, we want to offer that application as SaaS.
The main thing is to completely separate the user interface from everything else. Once you've done that, you won't be rewriting the application in order to port it - you'll just be creating a web UI on top.
NESBAWA (Not Everything Should Be A Web App).
I worked for a company that went through a similar situation with their monolithic WinForms application. From that experience, there are two things to consider:
1] Decouple all data access logic (DAL) from the existing WinForms UI. You can start this process before any web development begins.
We did this refactoring in a series of 6 weekly sprints. Some parts of the app were easy to change - others were made of completely hellish spaghetti code that interwove DAL, inline SQL and UI code all in the code behind of the WinForm.
Once you have this separation in place, supporting two different UIs is easier.
2] Ignore ASP.Net MVC and target WebForms. WebForms was designed to make writing a web application close to the experience of writing traditional WinForms UI code (event driven, component based).
You need to understand the page lifecycle, and there are a few conceptual gotchas around dynamically generated controls that tend to trip up a lot of newcomers - but otherwise it's the most painless way to get a team of WinForms developers doing web stuff. MVC maybe very popular in web circles right now, and it provides a better separation of concerns (though you can achieve similar results with WebForms with a bit if diligence and strong design leadership) - but it requires a higher degree of knowledge. With MVC you're working closer to the metal of the HTTP request/response cycle. WebForms abstracts away a whole lot of that for you.
Best of luck in your endeavour!
John is right.
However, have you heard of the "Empty Client" approach? This is a fairly new approach to developing .NET WinForms applications that can also run as web applications on plain browsers. That approach would allow you to develop your WInForms application and put it on the web if and when you desire with no additional development or adjustments.
One framework that does it is Visual WebGui
We have a large suite of apps, most are C# 1.1, but at least 10 major ones are in VB6. We are undertaking a project to bring up the VB6 apps to .NET 3.5.
All the c# 1.1 apps are written using a traditional n-Tier approach. There isn't really any architecture/separation to the UI layer. Most of the code just responds to events and goes from there. I would say that from the point of maintainability, it's been pretty good and it's easy to follow code and come up to speed on new apps.
As we are porting VB6 apps, the initial thinking was that we should stick to the existing pattern (e.g. n-Tier).
I am wondering, whether it's worth it breaking the pattern and doing VB6 apps using teh MVP/MVC pattern? Are MVC/MVP winform apps really easier to maintain? I worked on a MVC-based project and did not feel that it was easier to maintain at all, but that's just one project.
What are some of the experiences and advice out there?
Dude, if something works for you, you guys are comfortable with it, and your team is up to specs with it. Why do you need to change?
MVC/MVP sounds good... Then why am I still working on n-Tier myself?
I think before you commit resources to actual development on this new way of programming... You should consider if it works for YOUR team.
If you are porting the VB6 apps vs. a full rewrite, I'd suggest to focus on your Pri 1 goal - to get asap to the .Net world. Just doing this would have quite a lot of benefits for your org.
Once you are there, you can evaluate whether it's benefitial to you to invest into rearchitecting these apps.
If you are doing full rewrite, I'd say take the plunge and go for MVP/MVVM patterned WPF apps. WPF willl give you nicer visuals. The MVP/MVVM pattern will give you unit testability for all layers, including the visual. I also assume that these apps are related, so chances are you might be able to actually reuse your models and views. (though, I might be wrong here)
It moves a thin layer of code you still probably have on the UI. I say thin, because from your description you probably have plenty of code elsewhere.
What this gives you is the ability to unit test that thin layer of code.
Update 1: I don't recommend to re architect while doing the upgrade, the extra effort is best expend on getting automated tests (unit/integration/system) - since you will have to be testing the upgrade works anyway. Once you have the tests in place, you can make gradual changes to the application with the comfort of having tests to back the changes.
MVC in particular does not exclude n-Tier architecture.
We also have ASP.NET 1.1 business application, and I find it a real nightmare to maintain. When event handlers do whatever they like, maybe tweak other controls, maybe call something in business logic, maybe talk directly to the database, it is only by chance that software works at all.
With MVC if used correctly you can see the way the data flows from the database to your UI and backwards. It makes it easier to track the errors if you got the unexpected behaviour.
At least, it is so with my own little project.
I'll make the point once again: whatever pattern you use, stick to the clear n-Tier architecture. 2-Tier or 3-Tier, just don't mess everything into a big interconnected ball.
"Change - that activity we engage in to give the allusion of progress." - Dilbert
Seriously though, just getting your development environment and deployment platforms up to .NET 3.51 is a big step in and of itself. I would recommend that things like security reviews and code walkthroughs should probably come before re-archecting the application.
MVC and MVVM are excellent paradimes, particulary in terms of testability. Don't forget about them, but perhaps you should consider a pilot project before full scale adoption?