I have two very large WinForm applications built on the now dead Composite Application Block ("CAB") from Microsoft Patterns & Practices. I was an earlier adopter and jumped in first to embrace and use CAB. Well, now that it's truly dead I'm starting to think more and more about the future and what framework I can migrate to.
What I like about CAB:
* Structure, structure, structure - I lose focus easily and tend to suffer from "analysis paralysis". CAB introduces a "way to do things" and that keeps me on track and developing the application instead of worrying "how to wire up events, or what the best IoC is, etc.
* Actually... I think that's about all that I really like about CAB ;0)
I have seen articles about "build your own CAB" but I'm not interested in that. I'd really like to jump ship to a similar framework that is solid and actively supported. My web searches have not turned up anything that seems to serve the same needs as the CAB did. Maybe it's that everyone DOES build their own and that's why there isn't another framework out there.
If you have some guidance or advice I'd really like to hear it.
You can check out the
Smart Client Software Factory
OR the
Web Client Software Factory
I am not sure about specific features / patterns that are targeted by especially the SCSF v/s the CAB but i have been using WCSF for a while now and it definitely provides the structure that you like about CAB.
I believe these two do constitute the prescribed guidance from P&P and are definitely being updated.
I would suggest you porting your app into WPF - PRISM. I wish they had a PRISM way for Winforms too, but sadly they dont. We had two of our last enterprise level applications migrated using SCSF, now we have switched over to PRISM for the obvious reason. It does include initial learning curve, i knew wat WPF was and had my Helloworld app done with few extras. but now since we had to switch to PRISM WPF, i am having the steep learning on both! Good luck!
Related
I am developing a windows forms application and I want to add the ability for the user to create logical flow diagrams. Something similar to what is show in this screenshot: http://www.cocoontech.com/w/images/8/82/Premise_ObjectDiagram.png
Are there controls that can be used to do something like this? At least something that I can use as each block in the diagram. I was thinking of just using panels for them, but there must be an easier way.
Your link is broken. However, there are many diagramming components in .NET. Some of them are:
NWoods Diagrams: http://www.nwoods.com/
SyncFusion essential diagrams: http://www.syncfusion.com/products/user-interface-edition/wpf/Diagram
yWorks' yFiles: http://www.yworks.com/en/index.html
I don't know your exact requirements, but maybe you can leverage the Workflow Foundation (WF). You can create an application in which you host the workflow designers. If you're interested in using it I'd suggest the WF books by Bruce Bukovics:
https://www.apress.com/index.php/author/author/view/id/2050
The Pro WF (Windows Workflow in .NET 3.0) book contains an entire chapter (#17) which explains how you can host the designers in your own application. You could use it to visually create simple work flows that illustrate to the user how the logic is applied.
I am not 100% sure if this is appropriate here to link to specific products but since others do and what I am going to link to is 100% free code, let me share my solution too. Excuse me if I shouldn't.
I have faced the same (if I understand the question correctly) problem once and the only ready free solution I've found was NodeGraph. However, it seemed (and seems) abandoned and lacking what I consider proper model-view separation (I wanted it to do view only but found the actual model manipulation logic being a part of it).
So I've forked it and came up with FlowGraph which looks and feels the same for from the application user point of view (my sincere reverence to the original NodeGraph designer - it's an "eye-candy" IMHO, I've enjoyed how it looks and found nothing serious to improve in this aspect) but is some ways (listed on the project page) different from the developer's perspective. It can look abandoned too as I've uploaded the last version back in 2014 (3 years ago as by now) but it isn't - it is just stable (I am not aware of any problems with it despite it enjoying a fair degree of popularity) so far and I plan a major update soon.
I am doing lot of desktop application but using .Net WinForm.
But now for productivity as WPF provide lot of further. I am stating to doing development using WPF.
We are developing small application not very large but lot of enhancement comes for most of application.
I am just want know which WPF framework/approach for WPF is good for me with considering following point
Framework is Simple to understand and manage
If support Fast Development its very good for us
New enhancement its easy to add
Its Support UI management
Support new further link LinQ, Entity Framework
WPF, in general, doesn't really require a framework. Choosing an appropriate framework really should happen after understanding the basics.
There are quite a few good, lightweight "frameworks" that help fill in the gaps, such as MVVM Light and Caliburn Micro.
However, if you're new to WPF, I'd start at the fundimentals, first. I wrote a series of articles on moving to WPF from Windows Forms which explains how to think about WPF, and why you should try to think differently than you do in Windows Forms. Often, when people first start using WPF, they make assumptions (like the requirement for a "framework") based on their Windows Forms experience, and waste a lot of time that could be better spent just building the application directly.
To not scary you, but WPF It is not simple, especially if you are moving from Windows Forms. I, personally think it would be easier to someone who never did before desktop development, or at least WindowsForms dev.
So if you are searching for something to learn fast and boost your productivity, it's not about that.
Wpf is about testability, reliabity and scallability which is really beautiful and I strongly encorage you to begin to learn it. But consider that you will need understand and learn it, write basically more code then, may be, you did in WinForms. But this is a pay you have to pay for most advanced, flexible and powerful windows desktop dev framework I ever worked with.
In short, you have to learn it:)
I'm going to have to write a big system in January with ASP.NET MVC3 / C#, and need to know how to write a system that will WORK. I do have a bit of experience with ASP.NET MVC and C# but would not call myself an expert. It needs to be extensible so that I can extend it later with new features. How would one go about this? Is there books that explains this topic in detail or should I use trial and error?
In short I need to know good design practice in my code thats extend-able for the future.
Regards
RaVen
The System will be a community portal with forums ratings etc. Cant say more than that << Company Policy>>, The forums I can manage because of plenty open source options... But the rest is up to me.
SOLID == Great Success
Follow SOLID principles in any project and you'll do well.
With regards to core infrastructure/architechure, SharpArchitecture is a good place to start. It is by no means the perfect solution...BUT they give you a good framework to play with and you can have a working system quickly while learning the concepts that work and don't work over time. Take a look and see what you think. It uses NHibernate, Castle and MVC.
Test Driven development will ensure quality for your project. Be strict with yourself, red green refractor. One of MVCs strengths is that it's easier to test.
Professional ASP.NET MVC 2 is a good starting point, though, I would assume that they'll come out with an MVC 3 edition as well. The NerdDinner tutorial contains a lot of ideas on how to structure your application.
Basic advice: work with the MVC architecture, not against it. Understand your application, especially your data model, and layer that onto your application structure. Typically you'll have a controller per model, but not always.
If you want more detailed advice, you'll need to be more specific about your project. I'd suggest coming up with specific questions about various details of your design as you have them, rather than a single question covering the whole project. The latter probably won't get the kind of response you desire.
you can use my "awesome" demo as a start
http://awesome.codeplex.com
If it's going to have to be extensible, make sure you write tests. You'll save yourself sleepless nights in the long run when you fix something, but ended up breaking the entire system.
As far as how to make things "WORK" - that depends on your ability. Read, and look to improve things, but don't get caught in premature optimization or it will leave you dead in the water.
Based upon your edit and your abilities, it might be wiser to select an open source CMS written in ASP.NET MVC and support it. Your skills are good enough, it sounds like, to learn how to write modules and be part of a larger community. You do not sound like you really want to write the whole thing because you are timid about your skills, deadlines, etc. Whilst learning the ins and outs of a well written piece of software, one day you may choose to write your own or contribute to a core piece of the software. There are several to choose from see my comment above under your question.
edit: I also think this will allow you to just start and not worry about every design paradigm people will throw at you for success.
WhoCanHelpMe is a nice reference application. It's built upon S#arp Architecture which is a good starting point for an MVC-application using domain driven design. That will also help you on the way with wiring IoC and db-stuff.
Remember that not every example and framework will fit your requirements, so do as jFar said, think SOLID and make your own decisions based on principals.
You should also look into MEF for extensibility.
my team is minutes before developing the head application for our company and we ran into roadblock in our design. my team develops WinForms application in C#, .NET 3.5.
The first thing we need to do in our design is to decide which CompositeUI framework to use.
Well, first we were sure that we are going to use CAB. but is it the right choice considering P&P are not into it any more?? What about Acropolis? Is it stable enough and going to be here for the next few years??
So this is my question: what is the framework that is stable enough and is right for an application that will lead my team for the next 3-4 years?
your help is needed.
thanks!
If you're going to do WinForms, the Smart Cient Software Factory is the way to go. From what I've seen in the market, most people are going away from WinForms and moving toward WPF. I'm in the process of evaluating what it will take for my company to move from WinForms to WPF at the moment. I love the support for WinForms right now, but if your time horizon is 3-4 years, I would strongly recommend you take a look at WPF instead.
If you want to stick to Winforms by all means, there are quite a few third-party solutions out there (for instance Empinia or the Genesis Hybrid Smartclient Framework being shown on CodeProject) as well besides the Smart Client Software Factory. The question here remains whether they're stable enough and have enough stamina to still be around in 3-4 years.
On the other hand, if you're looking at this fairly long time frame, considering WPF might really pay off. Yes, it's a learning curve, and yes, the tool support in VS 2008 isn't quite up to snuff just yet. But things will get a lot better with VS 2010, and Microsoft will be investing a lot of manpower in WPF - VS 2010 itself is written in WPF.
For WPF, there's P&P guidance in the form of Prism, which is very promising and looks very well thought out. Going into WPF also brings you additional benefits of basically knowing Silverlight "for free" (it's a subset of WPF, at its core). So that might be an additional benefit.
Marc
Glenn Block posted some guidelines a while ago that could be of interest.
And Brian Noyes actually did a port of parts of PRISM to WinForms but I don't know if it's good and stable enough to be used as your platform for the next couple of years. =)
My company has developed a long standing product using MFC in Visual C++ as the defacto standard for UI development. Our codebase contains ALOT of legacy/archaic code which must be kept operational. Some of this code is older than me (originally written in the late 70s) and some members of our team are still on Visual Studio 6.
However, a conclusion has thankfully been reached internally that our product is looking somewhat antiquated compared to our competitors', and that something needs to be done.
I am currently working on a new area of the UI which is quite separate from the rest of the product. I have therefore been given the chance to try out 'new' technology stacks as a sort of proving ground before the long process of moving over the rest of the UI begins.
I have been using C# with Windows Forms and the .net framework for a while in my spare time and enjoy it, but am somewhat worried about the headaches caused by interop. While this particular branch of the UI won't require much interop with the legacy C++ codebase, I can forsee this becoming an issue in the future.
The alternative is just to continue with MFC, but try and take advantage of the new feature pack that shipped with VS2008. This I guess is the easiest option, but I worry about longevity and not taking advantage of the goodness that is .net...
So, which do I pick? We're a small team so my recommendation will quite probably be accepted as a future direction for our development - I want to get it right.
Is MFC dead? Is C#/Winforms the way forward? Is there anything else I'm totally missing? Help greatly appreciated!
I'm a developer on an app that has a ton of legacy MFC code, and we have all of your same concerns. A big driver for our strategy was to eliminate as much risk and uncertainty as we could, which meant avoiding The Big Rewrite. As we all know, TBR fails most of the time. So we chose an incremental approach that allows us to preserve modules that won't be changing in the current release, writing new features managed, andporting features that are getting enhancements to managed.
You can do this several ways:
Host WPF content on your MFC views (see here)
For MFC MDI apps, create a new WinForms framework and host your MFC MDI views (see here)
Host WinForms user controls in MFC Dialogs and Views (see here)
The problem with adopting WPF (option 1) is that it will require you to rewrite all of your UI at once, otherwise it'll look pretty schizophrenic.
The second approach looks viable but very complicated.
The third approach is the one we selected and it's been working very well. It allows you to selectively refresh areas of your app while maintaining overall consistency and not touching things that aren't broken.
The Visual C++ 2008 Feature Pack looks interesting, I haven't played with it though. Seems like it might help with your issue of outdated look. If the "ribbon" would be too jarring for your users you could look at third-party MFC and/or WinForms control vendors.
My overall recommendation is that interop + incremental change is definitely preferable to sweeping changes.
After reading your follow-up, I can definitely confirm that the productivity gains of the framework vastly outweigh the investment in learning it. Nobody on our team had used C# at the start of this effort and now we all prefer it.
Depending on the application and the willingness of your customers to install .NET (not all of them are), I would definitely move to WinForms or WPF. Interop with C++ code is hugely simplified by refactoring non-UI code into class libraries using C++/CLI (as you've noted in your selection of tags).
The only issue with WPF is that it may be hard to maintain the current look-and-feel. Moving to WinForms can be done while maintaining the current look of your GUI. WPF uses such a different model that to attempt to keep the current layout would probably be futile and would definitely not be in the spirit of WPF. WPF also apparently has poor performance on pre-Vista machines when more than one WPF process is running.
My suggestion is to find out what your clients are using. If most have moved to Vista and your team is prepared to put in a lot of GUI work, I would say skip WinForms and move to WPF. Otherwise, definitely look seriously at WinForms. In either case, a class library in C++/CLI is the answer to your interop concerns.
You don't give a lot of detail on what your legacy code does or how it's structured. If you have certain performance criteria you might want to maintain some of your codebase in C++. You'll have an easier time doing interop with your old code if it is exposed in the right way - can you call into the existing codebase from C# today? Might be worth thinking about a project to get this structure right.
On the point of WPF, you could argue that WinForms may be more appropriate. Moving to WinForms is a big step for you and your team. Perhaps they may be more comfortable with the move to WinForms? It's better documented, more experience in the market, and useful if you still need to support windows 2000 clients.
You might be interested in Extending MFC Applications with the .NET Framework
Something else to consider is C++/CLI, but I don't have experience with it.
Thank you all kindly for your responses, it's reassuring to see that generally the consensus follows my line of thinking. I am in the fortunate situation that our software also runs on our own custom hardware (for the broadcast industry) - so the choice of OS is really ours and is thrust upon our customers. Currently we're running XP/2000, but I can see a desire to move up to Vista soon.
However, we also need to maintain very fine control over GPU performance, which I guess automatically rules out WPF and hardware acceleration? I should have made that point in my original post - sorry. Perhaps it's possible to use two GPUs... but that's another question altogether...
The team doesn't have any significant C# experience and I'm no expert myself, but I think the overall long term benefits of a managed environment probably outweigh the time it'll take to get up to speed.
Looks like Winforms and C# have it for now.
Were you to look at moving to C# and therefore .NET, I would consider Windows Presentation Foundation rather than WinForms. WPF is the future of smart clients in .NET, and the skills you pick up you'll be able to reuse if you want to make browser-hosted Silverlight applications.
I concur with the WPF sentiment. Tag/XML based UI would seem to be a bit more portable than WinForms.
I guess too you have to consider your team, if there is not a lot of current C# skills, then that is a factor, but going forward the market for MFC developers is diminishing and C# is growing.
Maybe some kind of piecemeal approach would be possible? I have been involved with recoding legacy applications to C# quite a bit, and it always takes a lot longer than you would estimate, especially if you are keeping some legacy code, or your team isn't that conversant with C#.