After thinking for long, I have decided to build my data app for the Not-for-profit organization I work for (I don't program regularly there, though...) using C#, .NET 3.5 (using ADO.NET DataSets) and Scimore db.
I have done base basic tinkering till now and have found this combo to be quite good and fast. Ya, "fast" is a requirement for me, as our computers are slow.
I have a question though: should I use Visual Studio design tools to help me build my GUI for data bound controls or should I code them by hand? In simple scenarios, I have found that designer generated code seems to be too big for the purpose.
Will it somehow affect the "fastness" of my final app?
Thanks for reading!
Edit Sorry, I didn't mention, this would be a desktop application, using Winforms
Usually the amount of code does not affect execution speed so I shouldn't worry about that. Therefore, you should consider using the Visual Studio design tools for building your GUI. Most of the time you can build your application a lot faster this way.
if you're looking to keep your ASP.NET code as lightweight and fast as possible you may want to look at using ASP.NET MVC. This is the technology used to create StackOverflow, it gives you a lot of control over which data technologies you want to use to implement your site, and it for the most part avoids the overhead of using ASP.NET server controls. You may find this to be a great option for your needs.
Related
Any good resources for setting up a Windows Form with C#? Looking to create my first database application using C# and VS 2008. Thanks any advice is much appreciated.
http://windowsclient.net/learn/ has a lot of articles on Windows Forms, even though it's focus has recently shifted towards WPF
Well for a start off, use a good pattern (I found this the most important thing for WinForms apps, as the code soon grows to the size of Susan Boyle) - at the moment I like the MVP (Passive view or Supervising Controller) pattern. Links below are some of the best I've come across:
http://www.c-sharpcorner.com/UploadFile/rmcochran/PassiveView01262008091652AM/PassiveView.aspx
http://codebetter.com/blogs/jeremy.miller/archive/2007/07/25/the-build-your-own-cab-series-table-of-contents.aspx
As for Windows forms themselves, they're pretty straight forward with the not so obviuos pit falls - just make sure you de-register any events you register (mem leaks...)
But there is a good site (ahem codeproject ahem dot ahem com) with lots of guys on there who are just genius's
Check out anything by Sacha Baber, I'm working my way through this myself ATM:
http://www.codeproject.com/KB/cs/AutoDiagrammer.aspx
I would take a look at MVC or MVP to make your life easier and make testing a lot simpliar. Here are some good starting points:
What are MVP and MVC and what is the difference
Selecting a MVC MVP implementation for a Winforms Project
Implementing MVC with Windows Forms
There are some nice easy tutorials on MSDN to get you started on Windows Forms. How to: Create a Windows Forms Application is a nice introduction to building a basic Forms application. Then you could move onto the Walkthrough: Simple Data Access in a Windows Form for a little bit more advanced with some database interaction.
As you are going to be creating a Database application and interacting with SQL Server I would also consider looking into LINQ to SQL: .NET Language-Integrated Query for Relational Data. This will heavily reduce the complexity of your database interactivity. It will also automatically create ready-to-use Business Objects based on your Database tables which reduces the amount of coding you will need to do in your DAL. Scott Gu's blog article Using LINQ to SQL (Part 1) is a great starting point for learning L2S for the first time.
Also as others have already suggested, I would advise you read up on some design patterns to follow when implementing your application as it will probably help you in the long run when your application begins to get more and more complicated.
it seems like your mixing your terms up a bit.
Form is a window for a application, visual studio comes with a designer for those, that you can design your UI using drag and drop
For the database the microsoft sql server comes with a UI and a designer called Sql Server management studio. That allows you to design your entire database
So I've been learning C# for like a year now (I'm 20 years old) and I'm getting pretty confident with it. I've also been meddling with C++ every now and again. For example just recently I've been following the Nehe OpenGL tutorials for C++ and I find it a fun way of learning.
I want to start looking at creating cross platform GUI software after I stumbled across this library called FLTK (fluid something rather). After finally and painfully getting it to work I found it refreshing to know that there are solutions for GUI creation in C++, however I think FLTK looked pretty old.
So I googled around for some newer GUI frameworks and decided to start playing with wxWidgets (decided against Qt because of licensing).
I downloaded it, compiled it, and looked to see if there were any IDE plug-ins for RAD development, as you can imagine going from drag and drop a component onto a form in C# I was hoping for something similar.
I learned that code::blocks has something of the sort so I tried that out. It was alright but the thing that turned me off was the horrible code completion; it would only show members and methods in the current object and nothing for the #included header files. I understand that code completion/IntelliSense isn't easy for C++ but Visual Studio 2008 handles it pretty good. I did find some other RAD tools like wxFormBuilder but it costs money, not something I want to do for simply learning.
So my TLDR question is if anyone has had experience with wxWidgets? Do you just develop in whatever IDE you're comfortable with and just code the GUI? Meaning no visual helpers? Perhaps you could give me a nudge in what direction I should be going :)
Thanks, this is also my first post on this site albeit I have read many threads before that have helped me solve copious problems. Cheers!
My suggestion is to learn how to do GUI layout with wxWidgets in code, then when you get good at it learn how to use the GUI tools.
Doing this kind of work manually for a while gives you the understanding about what you need ("Ok, I need a wxSizer, vertical, to put these two horizontal wxSizers into, where I put my a wxStaticText and a wxTextCtl for each line ...")... where as I think if you started out with the GUI tools you'd just tend to get annoyed because (last time I looked) none of them were Drag And Drop editors like you get with .NET.
Definitely give Code::Blocks another try. It is a WONDERFUL environment to work with wxWidgets in. It comes with a form designer and templates for wxWidgets projects, so I can't imagine working without it.
Also, for a good beginner's introduction to wxWidgets, try this page. It helped me alot when I started with it.
I use wxWidgets without using a drag and drop designer. There are obviously drawbacks to that approach but an advantage is that you don't have any horrible automatically generated code to deal with. In the past I've found having such code in the middle of my project has caused various types of grief - especially if you decide it needs some serious changes it is often necessary to start from scratch because form designers are so much better at "writing" as opposed to "editing".
For simple applications you can assemble a UI using a mixture of customized and standard widgets without too much difficulty. Check out the wxWidgets samples and demos, which use that approach. My chess app (see my website) uses this approach too.
A more elaborate UI could possibly be implemented by writing something special at a higher level of abstraction. The kind of thing I am thinking of would be a subsystem that accepts high level flexible requests to provide different types of user interface functionality, and then sorts out the details of the controls to create and the positioning etc. of those controls itself. That is kind of a technical fantasy of mine but I haven't ever really attempted to do it. Actually, a fairly primitive facility of this type is already available and used by the demos I mentioned; It is called a "Sizer" (class wxSizer) and is basically a control container.
Finally I would point out that problems with the Qt licence have basically gone away since Nokia bought Trolltech and made it "more" free (LGPL licence). Many people think Qt is the way to go these days. I am pretty happy with wxWidgets but will definitely evaluate Qyt seriously one day. Good luck with your projects.
I have developed a number of application GUIs using wxWidgets - you can see screenshots at http://ravenspoint.com/
IMHO, you should distinguish between designing a GUI and implementing it. Expecting to use the same program to design your GUI and to automatically emit all the code to implement the design is expecting too much.
A design program should be fast and simple. I recommend http://www.balsamiq.com/
Once you have settled on the design, then you can turn to the coding. Personally, I find that placing widgets on a panel using the wxPosition and wxSize parameters of the wxWidget constructors to be trivial - easier than trying to nudge widgets into their exact positions using the mouse.
The trouble with using some kind of form builder to emit all the code for a significant GUI is that you end up with a morass of automatically generated code that is hard to find your way around in. If the code has been handwritten, then you already know where everything is located.
wxFormBuilder but it costs money
wxFormBuilder is Free and Open source
Also Visual Studio is best for C++ coding in wxWidgets, but you will run into lots of issues on Linux due to the way Visual Studio handles a lot of things, like file names you have to take extra care for case sensitivity.
Also regarding the GUI, add the wxFormBuilder to the Visual Studio solution, add the file type handler to Visual Studio. Now just double click on it and add your dialogs, like you do it in C#.
Just add the generated code files to the Visual Studio project once and you are done.
It's very easy to use Visual Studio with GUI programming in wxWidgets.
Also don't forget to watch the CodeLite editor if you want to port on Linux. It is very much compatible with the Visual Studio projects and shortcut keys.
There is wxGlade and wxFormBuilder.
I don't know if there is another one, but the wxFormBuilder I know is free and open source.
You will find links to other tools on the homepage
of wxGlade (http:// wxglade.sourceforge.net/).
Most of these programs are able to output xrc files, which are are an XML representation of your GUI. It address the issue of complexity of the generated code but is not as powerful.
Yet personally I don't use any of these tools, except sometimes to see what it's going to look like before I do it but never to actually generate code.
I just finished doing a hello world program in both wx and fltk using the netbeans IDE. Microsoft Visual Studio WinForms or MFC was much easier than either. I needed cross platform capability so I could not use it for this application. I finished fltk in much less time than wx. The program was simpler, smaller, faster, and easier to write. Wx had pretty disjointed documentation and organization. Fltk was designed back in the "old days" when small fast and efficient was valued. That's probably why it seems "old" to you. I'm an old guy so it worked for me. YMMV
I'm writing simple database driven application, 80% of functionality is CRUD operations on about 15 tables.
Coming from web development background I figured I can cover almost all of these CRUD cases with Rails scaffolding or say Django admins.
So I started to look around for Rails/Django-like framework but for Windows Forms applications (ofcourse I understand that "rich client" application
development significantly differs from a web development and I'm not expecting anything really similar).
I was surprised that except for a variety of ORMs (let's call it Model-layer) it seems like I'm left with little choice
when it comes to View-Controller layer. Maybe I'm missing something?
PS. I evaluated Visual Studio DataSet Designer, but it seems to work only for the most simple cases, and requires additional code for any slightly nontrivial task.
(added) so far I've found:
TrueView for .NET (thanks to Vijay Patel)
NConstruct
I would start to look at the Entity Framework if you can use .net3.5
Introducing the Entity Framework
How to: Bind Objects to Windows Form Controls (Entity Framework)
You could try DevExpress eXpressAppFramework. If I've understood you correctly it should do what you're looking for. It works with Winforms and ASP.NET and also has an accompanying ORM framework. There are some videos here that demonstrate the product. And there are forums here if you need to ask specific questions.
Did you check Rocket Framework for Windows Form
Everything is perfectly in order to support your requirement.
This use Entity Framework as the back-end
Use Object Data Source to Auto-Bind Object to UI
Use Generic to minimize the amount of code you need to write
Additionally, the documentation also is very well done and architecture is pretty good and stable too..
I am using it right now and it is serving me pretty well
As far as I know MVC framework for Winforms don't exist. I've thought about it but I think it would just get too constricting no matter how hard you tried. The fact you're not tied to a single page in a browser just completely throws alot of standards out the window. According to your needs you can have a single MDI form that would be similar to the web and web ideologies would be applicable, or you could have an MDI form that could be filled with MDI forms and standard forms and they could need to talk to each other to make sure they're up to date, even in the background which isn't an issue in webforms.
At the same time threading becomes a huge issue as a half a second wait on the web is nothing while if a program freezes for even that long you have problems. There are even more approaches to threading than there are to the MDI/Form Design issue.
I've almost always lived in the WinForms world and I tend to start with a VERY generic MVC implementation and let it evolve as needed to meet the current needs. I've yet been able to apply an entire previous implementation in a greenfield project.
Shameless plug: You could try our TrueView for .NET framework.
It's based on Domain Driven Design and the Naked Objects pattern. It provides an auto-generated 'explorer' style UI at run-time (no code generation step), but you're free to override forms with your own implementations.
What is the API to the database you will be using? If it's a SOAP web service you could use the Microsoft Smart Client Factory at CodePlex. If it's a local SQL Server database you should consider Entity Framework.
I am working with NHibernate, and a few code generation tools. MyGeneration is one and SmartCode is the other.
This question has been asked before, but I have looked at some other responses and found that the code generation tools in the nHibernate space to be pretty poor.
I might be able to get away with MyGeneration and SmartCode, but are there any other possibilities out there that you have specifically used, and would recommend?
I guess my criteria is that they must work with MSSQL 2008, and tools that are currently being developed would be good too as it seems that some of the tools are not being actively developed any more.
Also the tools would ideally generate the domain objects, and also the nhibernate mapping files - Fluent nhibernate would be good but not essential. It would be good if the templates and method of code generation could be tweaked.
I am a developer so am happy to get my hands dirty on the right tool to make changes.
Thanks.
I strongly recommend you take a look at Visual NHibernate
from Slyce. I have used all tools out there both free and commercial and found it to be the only one that does exactly what it says on the can and more.
It allows you to design your entities either from the ground up or from an existing database.
(source: slyce.com)
It is compatible with most existing dbs
with future suport for Postgresql.
It allows you to customise your entities to your specs
(source: slyce.com)
Other than its ability to go back and forth smoothly between entities and db during design, my most favorate feature is the Diff View
(source: slyce.com)
which shows changes it will make to code before it generates the code. So not only can you see the effect of your changes but you can also cancel the codegeneration in time or simply output to a different folder.
This tool has many many fine features and is now mature. Lastly, there is a 30% discount going on so ;-)
I was using Adapdev's Cudus in the past and now I'm using NConstruct (http://www.nconstruct.com) because I need also application generation, not just NHibernate mapping files.
It doesn't support SQL 2008 and I've contacted them about this issue because I also plan to migrate from SQL 2005 to SQL 2008 in the near future. According to their response newer versions will support it but I don't know when. Maybe more of us need to push them to get SQL 2008 sooner. Otherwise I like this tool very much.
I suggest taking a look at the Summer of Nhibernate series by Steve Bohlen, specifically Session 8 which talks about using NHibernate with a a pre-existing/legacy datastore situation. He uses MyGeneration and provides the template file he uses for doing so.
I've used CodeSmith and been very happy with it. I haven't used their NHibernate template but I know it is just one of the many frameworks they support. Have a look here.
You may want to keep an eye on ABSE (http://www.abse.info). ABSE is a code-generation and model-driven software development methodology that is completely agnostic in terms of platform and language, so you wouldn't have any trouble creating your own generators for NHibernate, MSSQL 2008 and anything else you wish. The big plus is that you can generate code exactly the way you want. The downside is that you may have more work to do at first to build your templates.
Unfortunately, ABSE is still work in progress and an Integrated Development Environment (named AtomWeaver) is still in the making. Anyway a CTP release of the generator is scheduled for January 2010, so we're already close to it.
The NHContrib project includes a tool called hbm2net to generate code. I've never used it, so I've no idea what sort of code it produces, but I know it uses NVelocity. Link to a tutorial.
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#.