I have to develop a basic "line of business" application with the usual functionality like orders, stock control, sales, reports, etc.
I will use WPF to develop this application to run on Windows but I want to develop it "open" so I can do a Windows Forms application using the same structure (maybe to run over Mono) or even a Silverlight module. Can someone that did something like that (and survived) give me a sugestion on a guideline or something like that where I can find good practices? I'm a Delphi developer with some intermediate knowledge on C# but there are so many "amazing" libraries, frameworks and patterns that I'm a little lost on what would be good for that project.
Something like: Use EF (maybe wait for ef4?) or nHibernate, or ADO.NET, and expose your data using WCF, or webservices, or forget Mono because of the flexibility loss, etc. Can someone give me a tip on how you would do it? If someone has a bad experience in this type of project, it would be nice to hear from you as well. There is a lot of learning in the wrong decisions too :)
Mono doesn't implement WPF, it's not even on the roadmap. I'm not sure about Entity Framework...
You could probably do it in Silverlight (which has an open source implementation), but it's not ideal for creating desktop (although it is possible since Silverlight 3)
Where do I start?
First, from your description, you're in over your head.
Second, you're trying to pick a technology stack when everything is new to you.
In the best situation, I'd recommend a good training class in a few of the technologies you mentioned so you get a better understanding of them. I'd also recommend a mentor, someone who's done this before.
Reality though, may not allow for training or a mentor. In that case I'd recommend writing several real-life throw away programs. Take one piece of business functionality and try to write it in a few of the technologies you mentioned. If one feels better, and gives you what you want DECISION MADE! Don't stop with the first one that seems to work, try some more.
You should also listen to some good podcasts. I recommend Dot Net Rocks for a good grasp of the technology. The earlier podcasts for this site were also a very good source for some design discussions StackOverflow podcast
Best of luck.
I had to do something very similar recently in WPF. I have an ASP.NET background, but I have never worked with WPF (or WinForms for that matter), and it had me stumped for a while, but the longer I have been working on it (about 3 weeks now), the easier it has gotten. I really just searched Stack Overflow and Google for code snippets similar to what I was doing, and worked through them and changed them as needed. My company bought a book that helped me out as well (It was WPF Unleashed published by Sams), and it was pretty good. I do wish you luck on your first WPF app.
If you separate the business model and business logic from the user interface,
using MVC (Model View Controller) or MVVM (Model View View-Model) or a simular design pattern,
then you can have multiple user interfaces connected to the same business model + business logic and even connect the same user interface to other business models + business logic.
Thank you all for your suport... Brad, I'm already following your advices, doing some test cases to see what looks good... my problem is that altough I can develop an application in WPF and have a intermediate understanding in using the wpf databindings, generics, linq, anonymous objects, all the cool stuff, I always hear about this and that as the solution for all the worlds problems (like mvvm, or parallel programming, or functional languages, etc) and makes me feel "wrong" in my decisions and a bad developer if I do not use any of this nice technologies. I know the concepts but do not dominate it, and seems a lot of things to learn, sadly I do not have that much time.
Thomas, exactly because mono do not support WPF i want to make the application as isolated as i can, so I can do a simple winform layer to manipulate the data.
darthnosaj, thank you, I'm doing that too, searching internet and found much information (and this nice site full of hellpful people :) )
And Danny, thats what i think i need... will take a look on some sample applications using mvvm and see if that works for me. For what i heard is almost a crime not to use in that case in wich I want that kind of isolation.
Again, thanks all :)
I would suggest you keep your application N-Tier. Make all the entities, data adapter, and business logic separated from the actual desktop application. This way you can use WPF on the Windows platform and use Mono/GTK# on the Linux/Mac platforms.
You will only need to write duplicate code to support the actual GUI application functionality, while your code from the separate entity/data access/business logic library (e.g. DLL/class library) can be used in both your WPF and Mono/GTK# projects. Just add the DLL as a reference to the WPF and Mono/GTK# projects.
There is a good video from Channel 9 on building N-Tier applications
There is also MSDN documentation and guidelines on building N-Tier applications
Related
I am trying to port an existing C#-WPF-Project as an iPad-App.
As far as I found out by now, the best way to go would be to use MonoTouch and reuse as much C#-Logic as possible.
As the original project is written with WPF for an actual TabletPC, my question is, if there is any way, to reuse the WPF-sources or at least minimize the part I have to write again.
If there are any good alternatives to MonoTouch, I would appreciate tips too :)
UPDATE: Your comments were helpful, but are not 100% what I was looking for. MonoCross looks nice, but as far as I understand, it just "hides" the iOS-specific part. What I would really love, would be a way to reuse the handwritten "special" WPF-Controls. (Or at least minimize the work/time to transfer them.) This would be awesome.
UPDATE 2: Maybe I should add, that I would also accept some "complicated" three-step-technique. For example, is there a way to translate the XAML-WPF-files to HTML5 (or something equally powerful) and then use Titanium or PhoneGap? The Languages and Frameworks shouldn't be the big problem, I just try to find a way to reuse as much as possible :)
Please see this previous question which is related and may be of interest on creating cross-platform iOS, Android and WP7 applications.
In response to your question, no it is not possible to re-use WPF Guis on iPad, IPhone, Android. Only Windows Phone will support silverlight views. To workaround this you must use a Model View controller architecture (as iOS, Android won't support databinding via MVVM) on all three and create separate views for each architecture.
While this may sound laborious, please note that if you correctly architecture your application so that key business logic and presentation logic is inside the Controller (or services) layers then you can re-use a large proportion of your code. This is the same limitation as if you create cross-platform code to dual deploy to Silverlight and WPF on Windows. The Xaml files often have to be specific to each framework, however often *.cs user controls and viewmodels / code logic can be shared.
UPDATE: Following your Update(2) in question.
Yes, you can use a third party server to translate XAML-WPF-files to HTML5 - the ComponentArt Dashboard Server. This claims to translate WPF/Silverlight applications written using strict MVVM to HTML5/JS for portability across multiple devices. I can't vouch for how effective this is and I do know it is expensive, however if you are seriously stuck and want to port WPF -> HTML5 then it is worth investigating this.
Best regards,
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
I am building a prototype for a web-based application and was considering building the front-end in HTML, which can then be reused later for the actual application. I had done a Flash-based prototype earlier, which embedded the .swf into a C# executable. Flash made for rapid turnaround time while the Windows application provided unlimited access to fancy API's for DB access and sound.
I want to consider something similar for this one too. Does this approach make sense? I am particularly concerned about the way the HTML would communicate with the container app. From what I understand out of preliminary research, it would be only through JavaScript, which might quickly get unwieldy. This is especially so because unlike the Flash-based prototype which implemented a lot of its functionality in the .swf, the HTML UI will depend entirely upon the shell to maintain state. Also, I don't need anything more than access to a database. So a desktop application might be overkill.
Another alternative that comes to mind is to build the prototype using PHP and deploy it with a portable server stack such as Server2Go or XAMPP. But I've never done something like this before. Anybody here shed some light on drawbacks of this approach?
The key requirement is rapid iterations of the UI, reusable front-end code and simplified deployment without any installations or configuration.
Some of the best programming advice I've seen came from Code Complete, and was along the lines of, "evolutionary prototypes are fine things, and throwaway prototypes are fine things, but you run into trouble when you try to make one from the other." That is, know which type of prototype you're developing, and respect it. If you're developing a throwaway prototype, don't permit yourself to use any of it, however tempting it may be, in the production system. And if you're developing an evolutionary prototype - one intended to become the production system - don't compromise quality in any way.
It sounds like you're trying to get both, the rapid development of a throwaway and the reusability of an evolutionary prototype - and you can't. Make up your mind, and stand by it. You can't have your cake and eat it, too.
I think you off to the wrong start, here. Why would you want your prototype to be fully functional? A prototype is intended to be throw-away and to help flesh out requirements and UI. If you need full functionality, why not just skip to the final product? If prototyping is really something you want to do, I suggest looking into a specialized prototyping tool.
Are you prototyping the user interface for a customer? If you are, consider something less unwieldy like paper prototypes or presentation software (like PowerPoint) until you get the UI nailed down. If you can establish the UI and are clear about the customer's requirements, you can then develop the application in whatever the actual platform is going to be with a clear model in mind.
In my current project, I prototyped the UI in PowerPoint first. In a subsequent iteration, I used static web pages and some jQuery plugins to simulate actual user interaction. That proved to be very effective in demonstrating the interface, and I didn't have to build the application first.
I would join in on folks suggesting paper prototyping as the "idea", but not necessarily the implementation. The biggest point here is that tools such as HTML or Flash let you get "bogged down" in the details - what does this color look like? What's the text on this thing? Lots of time can pass by that way. Instead, what you should be focusing on is user flows.
One tool that keeps the spirit of paper prototyping without all the "paper" drawbacks is Balsamiq: http://www.balsamiq.com/demos/mockups/Mockups.html. It was covered by Jeff and Joel in one of the Stack Overflow podcasts; I've been using it for my own projects for a while. It's freeware, and it does its job magnificently.
If you know C# then another option you can look at is Silverlight. You can then leverage your knowledge of C# and/or JavaScript and interact with a rich object model.
Would that do what you are looking for? The installation would be minimal on the part of the client - download and install the Silverlight plugin
If prototyping is something you truly wish to accomplish here, paper and pencil will be your best friends. You can draw out as many iterations as necessary. While none of this is ultimately useful later on once you begin coding, it is as quick and rapid is it goes.
As mentioned previously, there are many prototyping tools which have a bit of a learning curve, but an alternative to consider would be using a framework such as CakePHP or Ruby on Rails which make for fast application logic and leave customizing the front end being the primary hard work left. And plus, you're left with a mostly functional application when you're done with your prototyping which can be tweaked as needed.
In either scenario, you're paying with your time either upfront (in the case with learning a new framework), of over time in payments (with the case of prototyping on paper or coding by hand).
I have been a web developer for my entire development career. Nearly 100% microsoft focused the entire time. I have been using .Net, both C# and VB.Net, since beta. I now find myself in a position to where I have the opportunity to start doing some WinForms development in C# using the 3.5 framework. As with anything new, I am excited about the learning opportunity in front of me.
I am curious if anyone has any suggested books, articles, feedback, etc on the topic of transitioning from web development to winforms in the .Net world.
I think it goes without saying that the paradigms are very different. I really enjoy C# because of how easy it is to write great windows software.
Start by getting into the IDE and creating a real but small project. One of my first C# projects was a light weight budget program. That took me into many areas of C#, from XML handling to custom windows controls, to debugging, and more.
Experience is the best teacher. Take time to look at the function lists, and peruse the documentation. Get a feel for what is in the thousands of classes that make up .NET.
Reading books can be nice, but getting your hands dirty (in conjunction with a good book) is far more effective.
Set a goal and go for it, you will have no problem learning all about it. Don't be afraid to try things and take risks -- it helps you learn the system.
If you are moving from Web to Windows, there is a some significant differences between the two enviroments. Some good and some are bad. If your .Net based and moving to 3.5 look into WPF since it is the best of both worlds for Web developers converting right now.
I do know of some common mistakes made by web developers making the crossover. They would include:
Opening database connections on every form and every database calls. (In Windows Bad)
There is no ViewState concept or Stateless concept in Windows
I am sure there is a few more that can be added but right now I can't think of an exact list.
I do agree with gahooa, look at doing a small project and read as much as possible on the subject. Approach it as if you never developed before, and the skills you gained over the years will automatically kick in when needed.
I've created a simple desktop application in C# 3.0 to learn some C#, wpf and .Net 3.5.
My application essentially reads data from a csv file and stores it in a SQL server CE database. I use sqlmetal to generate the ORM code for the database.
My first iteration of this app is ugly as hell and I'm in the process of refactoring it.
Which brings me to my question. How would you architect a desktop database app in C#?
What are the best practices?
Do you create a Database Abstraction Layer (DAL) which uses the sqlmetal generated code? Or is the generated code enough of an abstraction?
If you use DAL pattern, do you make it a singleton or a static member?
Do you use the View-Model-ModelView pattern with the DAL pattern?
Apologies if this seems like a long open ended question, but I have been giving this a lot of thought recently.
I see a lot of examples on how to architect an enterprise n-tier app in C# but not that many on architecting standalone desktop apps.
I would start with the Composite Application Guidance for WPF (cough PRISM cough) from Microsoft's P&P team. With the download comes a great reference application that is the starting point for most of my WPF development today.
The DotNetRocks crew just interviewed Glenn Block and Brian Noyes about this if you're interested in hearing more from them.
Even better, Prism is not nearly as heavy as the CAB was, if you're familiar at all with that from the WinForms days.
The answer is "it depends" as always.
A few things to think about:
You may want to make this fat client app a web app (for example) at some point. If so, you should be sure to keep separation between the business layer (and below) and the presentation. The simplest way to do this is to be sure all calls to the business logic go through an interface of some kind. A more complex way is to implement a full MVC setup.
Another thing you may consider is making the data access layer independent of the business logic and user interface. By this I mean that all calls from business logic into the DAL should be generic "get me this data" rather than "get me this data from SQL" or even worse "run this SQL statement". In this way, you can replace your DAL with one that accesses a different database, XML files, or even something icky like flat files.
In short, separation of concerns. This allows you to grow in the future by adding a different UI, segmenting all three areas into their own tier, or changing the relevant technology.
Before architecting anything you should define requirements for your app.
It's a common error of beginner developers - starting writing code ahead of thinking about how it would perform. My advice will be to try to describe some feature of you application. It will help you to feel how it should be implemented.
As for useful learning resources I would highly recommend you to take a look at CompositeWPF it's a project designed specifically to teach developers best practices of desktop app development.
I'd start with Jeremy Miller's Build Your Own Cab series.
I was an early CAB adopter. I learned a lot from digging into that technology and reading all the .NET blogs about application architecture.
But recently I had a chance to start a new project, and instead of using CAB I went with StructureMap & NHibernate and borrowed some of the patterns that Jeremy uses (in particular, his way of handling event aggregation). The result was a really simplified, hand-tooled framework that does everything I need and I love working with it.
As to the specifics of your question: I use a Repository for data access. I initially wrote some ADO.NET code and used data readers and mapped my objects. But that got old real fast, so I grabbed NHibernate and was really pleased. The repositories use NHibernate for data access, and my data access needs are pretty simple in this particular app.
I have a service layer (exposed via WCF, Duplex channels) that utilizes the repositories. My app is basically client-server with real time updating (and I know your question was just about clients, but I would use the same technologies and patterns). O
n the client side I utilize MVP with StructureMap for IoC and some very simple event aggregation strategies for cross-class communications. I code to interfaces for just about everything. The only other thing I did was borrow from the CAB the idea of a flexible "Workspace" for dynamically displaying views. I wrote my own Workspace interface though and implemented my own DeckWorkspace and TableWorkspace for use in my app (these were really simple things to write).
A lot of my decisions in this most recent application were the result of experience and pain I felt using other frameworks and tools. I made different decisions this time around. Maybe the only way to really understand how to architect an application is to feel the pain of doing it wrong beforehand.
I would say yes, it could easily be structured towards smaller applications. There is a learning curve towards getting started, but honestly, it helped me understand WPF better than attempting to start from scratch. After starting a project with CompositeWPF and then starting another project without it, I found myself attempting to duplicate features of CompositeWPF on my own because I missed those features! :)