I have a c# windows form app in which we did a rapid prototype for the client. The extent of my c# experience has been with ASP.NET/C# so its a bit different when it comes to the actual structure of the software. Time is a factor in this project since it is a school project and we have a little under 2 months to be done.
The software will be mainly database driven.
Current Project Design
Currently there is 1 main windows form and a bunch of class files.
One idea we had is that since most of the actual code of the program will be in classes, should we just split the windows form up into a bunch of tiny windows forms with one main driver so to speak? or just leave it as one large form and try to have as little code as possible in the main win form?
What are your suggestions on the design of a c# database driven windows form app?
Please give pro's and con's to each.
Personally I favor an MDI (Multiple Document Interface) over a single form because a single form can become cluttered without careful planning. Also most clients like the idea of a MDI for database driven apps because it reminds them of Microsoft Access. I also like the idea of breaking everything into classes. The rule of thumb that I use for deciding weather or not to make a class is "Will I ever in my programing career need to do X again?". In this case X is what you would put in that class (e.g. Determine Leap Year). If you think that your form won't become cluttered then totally go for a Single form. Hope this helps you decide.
While I agree that you almost certainly want more than one form, I'm not at all a fan of MDI. Rather, I prefer to think about the common tasks that users will perform and design application around the user's expected work-flow, such that there is a natural progression from piece to piece. Of course, that also means providing a way for power users to get past this expected flow when they really want to.
A monolithic form that provides "kitchen sink" functionality is every bit as bad as a monolithic class that provides "kitchen sink" functionality.
Since it's a school project, I'll assume you're still learning this stuff.
Break the application down into smaller forms that do less. Each form should do one thing and do it VERY well. Its functionality should be well defined, cohesive, and as loosely coupled as you can make it. Try to keep the database code out of it (move that code into your classes, and invoke them from the form).
A form is nothing more than a way to display the information that is returned by the classes (in other words, a view on the data). Keep it simple like that and you will find it much easier to add new forms, change the existing forms, and extend your application down the road if you need to.
Related
I'm taking my first class in C# development for winforms. I'm using VS Premium 2013.
We've been working on an application all semester. For our final project one of our tasks is to convert it from an SDI to an MDI.
The mainform is structured as follows:
menustrip
toolstrip
split panel with a treeview control in its own class, a listview control in its own class, and a rich text box in its own class (these are all then displayed on the mainform)
user control that functions as a status bar docked at the bottom of the form
The code for all the click events and business logic is already written. This is already a robust application.
Is there a "best practice" for converting an SDI like this to an MDI? There's a ton of code here, and unless I get better guidance, I assume I'm going to have to create a new project, move over the classes that I can and then rewrite all the supporting event handlers and associated logic.
Is there a more time-efficient option that someone can recommend?
There is no single answer because the specifics of the migration depend on the specifics of your current application. If you have written it well then there should be almost no change at all. It should be mostly just setting the MdiParent of each document form before showing it. There would still be a few details to consider but that would be the bulk of.
So that changes like this are relatively painless is one of the main reasons that design patterns are used in development. Also, the less coupled the types are in your project, the easier they move around in these cases. For instance, if you have two types that each rely on the other to be exactly as they are then any change is going to have significant impact on both. If those types are decoupled though, a change in one may have absolutely no effect on the other.
I'm developing WinForms application. By far I've finished about 50% percent of it.
Is there anyway I can convert it into a Web Application without rewriting the whole GUI?
If there is non, in what platform should I use instead (rewriting my project) for having easily both Web and Windows UI?
Is there anything new in this subject in the last 3 years?
I know of course WPF and Silverlight are quite alike, but I'm not sure this is the bust solution.
This will be dependant on how you have constructed your architecture. The main reason WPF and Silverlight are interchangeable are because they tend to use MVVM patterns and architecture (also things like PRISM)
http://msdn.microsoft.com/en-us/library/ff921075(v=pandp.20).aspx
In theory if you follow the pattern you can drop the front whenever you like and and design it using something completetly different. This is known as:
Making your UI loosely coupled.
If you wanted to switch your front end display to a web application you would obviously have to change the UI layer to use HTML, in theory if you have given your application a suitable architecture your business logic should be able to remain the same, however if you have a lot of logic tied into the multiple Windows Forms i'm afraid you will suffer a long and painful migration process with many bugs along the way.
Think of your application as a house - you have the main foundations for the house (insulation, bricks etc.) which you may want to change from time to time to bring the structure up to date, however the fundamental foundations will normally remain the same. You can however decorate the house with however you wish without affecting the fundamentals (sorry for a poor analogy).
Hope this helps somewhat.
EDIT:
I just noticed you wanted to know the best architecture to use with a project, personally from what I know I would use PRISM, WPF and MVVM - you can Build WPF and Silverlight Applications with a Single Code Base Using Prism
I have never used MVC before and would like some advice.
I have actually already written quite a bit of code, but looking at it, it seems to be quite highly coupled between classes and there is a lot of code written on the actual main form of the winform. I am a University student, recently started on a 12 month placement, so do not have much real world experience.
My system is effectively a WinForm GUI that has, amongst other things, a treeview that is popualted at load via an event. And then when the user clicks on a node, it gets a datagridview from a dllplugin (which obtains the data from an Oracle DB via a perl script.
My question, is would MVC apply in this circumstance, and would anybody have any good advice/resources on how I can now, post-design to implement it?
Thanks.
The MVP pattern is more adapted to WinForms applications. Here's a nice article you may take a look at.
Received wisdom is that MVC is good for the web but has some constraints when operating in a desktop environment (I'm not sufficiently experienced in applying this sort of pattern in either context to make a worthwhile judgement).
The pattern that Microsoft (for one) are pushing for forms use is MVVM - which is Model View View Model - and it provides a similar set of benefits in terms of separation and testability. Even allowing that I could wish I knew more I can see what and why, especially if you're looking at WPF (and Silverlight) but in any context where you're trying to ensure separation.
The MVC pattern can work well with WinForms, see this question.
There are lot of related pattern to choose from; in the case of WinForms (unlike WPF) there is no clear winner.
Partly this is due to everyone having different aims, do you care most about:
Code reuse between Forms in the UI
Being able to support form the one UI system
Easy unit testing
Etc
Okay, I'm biting the bullet and deciding to get into the whole Microsoft/C#/.NET culture and I'm going to do this by putting together a simple (hah!) application.
It will basically be an application in which I want to store images and associate with them other optional things.
It must be able to import images from the filesystem (and hopefully camera/scanner) then allow the user to add text, audio and other information.
I plan to store the images and auxillary information into a database. What the application will do with said data isn't important (yet).
Keep in mind I know absolutely nothing about C# or .NET although, as an old codger, I know a great deal about many other things and will regale/bore you with stories and anecdotes until you quietly slip away :-)
What are the first steps to take in developing such an application? I've already set out UI layouts and likely process flows although it may be that the development environment dictates changes.
Development environment is currently XP SP3 + VS2008 (though I can upgrade if absolutely necessary).
What should I be looking at as the first step? Are there any gotchas I should be looking out for?
Have you decided for win forms or WPF? I've been doing win forms for the past 4 years and WPF was a great discovery for me, with the flexibility it affords. It might be fitted for your application and the different types of content you'll want to add and give you a flexibility that win forms can't give.
As for actually developing, I think loading images from the disk would be the first step, showing them in the UI and getting user input for them - you would get to work with the different objects and see how the framework handles things.
A tutorial about the field validation I mentioned in my comment is here - haven't done it, but something similar. You can also see the xaml code paired with the C# code there.
After looking for the differences between win forms and WPF I found that there are a few win forms controls that are missing from WPF. More on that on MSDN (compariosn chart) and a post from March with a more detailed chart.
It's also worth mentioning that you can include win forms controls in WPF applications and vice versa, but there are some limitations.
Just a couple of pointers, it would be easy to overwhelm you as you are just starting with this tech stack. First step, use SQLServer 2008 Express, it has better ability to deal with image data (images can be saved directly to the filesystem, but they are still in a table).
Apart from that, you can design your screen with the GUI, and then hook the bits up one by one to your retreived data. Create a new Windows Forms app, or a WPF one, and start from there (i'm assuming that you know about the toolbox window and just dragging components on to the designer and setting their properties in the Properties window).
If you're looking win forms you're going to have drag-and-drop UI pretty easily.
If you want to use a database than you're probably going to find MS-SQL the easiest to cooperate with. Look up LINQ-2-SQL, it lets you access your database through an object layer by simply dragging your tables onto a pane.
Fun things to use: extension methods, partial classes, LINQ (query any collection with inline lambdas) and even class/method attributes.
My $0,02:
a) Get to know the platform a bit, types, collections, events/delegates(/lambdas), etc etc
b) Dive into WPF
c) Learn about database connectivity (LINQ2SQL or NHibernate (or ....)
d) Learn about the MVVM pattern to get to deliver solid wpf applications, doing so forces you to dive deeper into the workings of WPF (routed commands, tunneling/bubbleing etc)
e) Learn more about patterns to get a more solid grasp of OO (this: http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=sr_1_1?ie=UTF8&s=books&qid=1276066663&sr=8-1 is an absolute pearl for that)
f) etc
If you aren't too desperate to get your hands dirty straight away I'd suggest this book: CLR via C#.
It is written for those with programming experience on platforms other than .Net and provides a clear and comprehensive explanation of C# and how it runs on the .NET CLR.
By reading this initially you might avoid writing some of the poorly constructed applications that many of us wrote before properly understanding the technology.
Buy a book on C# & .NET FW fundamentals!
Read! :-)
Read good books about .NET for example CLR via C#.
Read this:
Hidden Features of C#? https://stackoverflow.com/questions/380819/common-programming-mistakes-for-net-developers-to-avoid
How do I design a user interface for external hardware which is running in real time?
Is this possible with Blend 3?
I need to design a two way interface for a piece of external hardware and it would be great if I could twiddle it's knobs while designing as opposed to continually building, running, trying etc. The GUI is a lot more involved than just mimicking the knob positions and would probably need extensive use of converters and multiple binding.
Would I need to build two projects? One, to interface with the hardware and keep an image of the knob positions as dependency properties. This could, perhaps, be running while designing. Is that doable? Or is there a better way?
Using C# Visual Studio 2008 Express and Expression Blend 3.
There is a button labeled "Add live data source".
Thanks
When done carefully, you can separate the presentation from the model of data that you work with. Is it possible to "mock" up the data that you'll be operating on for your design sessions and then plug in the different models for your real time once you're acquiring the data?
One of the developers I work with not only mocked his model of the data but wrote tight loops on background threads to modify values so he could "fake" what his real UI would look like.
Not sure if that answers your question but it might get you thinking along the right path.