I need to develop a forms application with a DB backend. In future this may be linked to ASP.NET page. I was thinking of doing this as an MVC and reuse later.
So, What kind of MVC frameworks do you use?
I am interested in building forms quickly and any frameworks that link/bind control to database fields.
There are no really famous MVC frameworks for Windows Forms. There is probably a good reason for this - it's really difficult to implement MVC with Windows Forms due to the nature of the technology. I think you're much better off using MVVM with Windows Forms and I'm saying this as a huge fan of MVC.
Otherwise you need to give us more details of what you're doing and then we could probably offer some better advice.
This O/R-Mapping-Framework includes a Solution for the MVC and Command-Pattern, which is recommended for Desktop-Applications.
There is a Demo-Application which demonstrates a simple Win-Forms-Application.
In my knowledge there isn't a specific mvc framework for winforms, as for web applications (mvc2) . You'll have to implement the mvc (or better mv presenter) pattern by yourself. See this link http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
MVC is really only a pattern to structure your code around.
If you are really going to take your app and port it to be available over the web later on then may I suggest that you code it as a WPF application using the MVVM pattern as this will involve less work in the long run.
Alternatively if use ASP from the start.
Related
I am designing a windows form application. I want also to provide a web based front for the same application. I understand that I need to redesign the UI part wholly and I am ready for that.
But what I would like to know is that what architecture should I follow during development of the windows form so that the maximum part can be reusable. By maximum part I mean the data access logic, the business logic etc.
I am planning to use Rocket Framework http://rocketframework.codeplex.com/ for windows application design. Are any one familiar with it? Please suggest.
After a lot of R&D and extensive study I finally settled here: https://github.com/geersch/ModelViewPresenter It is an MVP architecture written by Christophe Geers. It supports all I needed- Architecture for winform, web portability support, Entity Framework. Really nice and easy to use.
Additional reading:
http://www.cerquit.com/blogs/post/MVP-Part-I-e28093-Building-it-from-Scratch.aspx
MVP or MVVM should enable use to re-use portions of your application.
Of Interest?: Implementing MVC with Windows Forms
I'm done some WinForms work in C# but now moving to have to develop a web application front end in .NET (C#). I have experience developing web apps in Ruby on Rails (& a little with Java with JSP pages & struts mvc).
Should I jump straight to MVC framework? (as opposed to going ASP.net) That is from the point of view of future direction for Microsoft & as well ease in ramping up from myself.
Or if you like, given my experience to date, what would the pros/cons for me re MVC versus ASP.net?
thanks
Have look here it will help you Choosing the Right Programming Model
If you need to work really close to the wire then MVC is a great choice. By this I mean, if you need to have very tight controls over markup then; while acheivable with WebForms; it is much easier with MVC. This would be common for applications that are targeting a public (e.g. internet) audience which might have a richer graphical experience. In contrast, if you're developing an internal (e.g. intranet) business application where graphical presentation is not as critical, then WebForms has a lot of really nice enabling capabilities that will allow you to move more quickly.
Don't get me wrong, you can make WebForm applications look really really nice, but you give up some control over the markup.
Very often ViewState comes into this kind of discussion. MVC will not have any ViewState so the on-the-wire footprint will be much smaller which translates to speed and bandwidth cost savings at some point. On the downside, making stateful applications with MVC can be more painful. In contrast, WebForms will carry ViewState by default and are inherently more stateful. This is typically fine for internal applications. Keep in mind that ViewState does not have to be sent over the wire... there are extensions that allow you to offload that to a local cache. I'm not favoring one over the other, but you should be aware of what each can do in this regard.
If unit testing is important to you then MVC is also a much better choice, as this is easier as well. This is totally acheivable in WebForms but requires you pattern your code behind correctly.
Security is not a major factor since much of setting up the IPrinciple and IIdentity occure in the HTTP pipeline via HttpModules, so either will do in that regard.
Another major factor in making your choice relates to your skills relative to the time you have to deliver... If you're not used to working in a stateless manner or coding standard web technologies (e.g. html, css, jquery, etc...) MVC will take you longer to do very basic things. With that said, once in place it will likely be cleaner, smaller, more testable, and faster. If you need to move very quickly there is a lot you can do faster in WebForms. WebForms also does a lot of heavy lifting with respect to markup so there are a number of details you can leave to ASP.NET.
I actually use both for a variety of reasons, and MS has stated they plan to continue support and development for both.
MVC is part of ASP.NET. You must mean MVC vs Webform to which the answer would be: coming from a Winform background, you will find webform easier to use. For the future, go MVC.
I used to work on desktop applications too, and never really got into web stuff. I didnt even (gasp!) knew HTML (yeah, that was my programmers shame). In my new job we were going to start a new application using ASP.NET MVC and I gotta tell you, I love it. HOWEVER I think you should only go with MVC if you are or you count with someone with good html/css design skills.
Html is easy I know (I've learned it know!) but I think its kind of hard to make nice designs with html and css, specially if you suck at designing and you could probably do prettier stuff using webforms, which is a little bit easier/similar to winforms.
Also, if you go the MVC way make sure you have enough time to learn it, since you are going to go a little bit more low level, gonna have to learn more of the little details, like the actual difference between post/get and all that stuff that is pretty much completely hidden in webforms. I would really recommend getting a book, I used this one Pro Asp.net MVC and really liked it.
Finally, if your page is gonna have interactive bits, or ajax-y things, if you go the MVC way you are more likely gonna have to learn javascript/jQuery too. If you go the webforms you can use the included drag'n drop ajax controls.
Coming from Ruby on Rails or other MVC based frameworks ASP.NET MVC is almost the best choice. (ASP.NET MVC is actually only the "VC" part, so you have to add an ORM of your choice. EF and Linq to Sql is the Microsoft way, NHibernate or other ORM's are the other way. One good quick start project is S#arp Architecture which uses NHibernate as the "M" part, or you can check out WHCM, which is a project built on S#arp Architecture and other good frameworks (it is considered an ASP.NET MVC best-practices demo project) ). ASP.NET MVC uses almost nothing from the WebForms package (the only exception I found is the AntiForgeryToken), so you'll loose nothing if you're unfamiliar with ASP.NET WebForms.
But as you said you have also made console applications, which ASP.NET WebForms resemble more.
If your project is new, I advise you to use ASP.NET MVC. If your project clearly separates the M-V-C part (like in S#arp Architecture, where they reside in different assemblies), creating a console application that uses the same business logic shouldn't be too hard. If your current project is to port a WinForms application to the web, then it might be easier to use WebForms.
I should get familiar with the language before using "fancy" stuff like MVC, because it's just way easier to learn when you could almost think in the language (but it's not necessary).
Horses for courses. If you're slapping together a quick app for someone, web forms is probably quicker and easier.
If you're building a long running enterprise app MVC gives you better testability a SoC.
I'm currently working on a project that has a sizable amount of both client and web code. The client code is written in C# and the web piece is written in PHP. Maintaining consistency between the two worlds is becoming cumbersome, and I want to consolidate the web code to .Net.
The issue is that I hate web development in ASP.Net Web Forms. I want something as raw as PHP, just using C# instead. I've read a little about ASP.Net MVC, but it looks like it abstracts too much of the request logic for my liking.
Does anyone know of a lightweight way to allow C# + .Net to handle web requests? Should I be looking more closely at MVC?
Update: I went with ASP.Net MVC and I've been very pleased so far.
If you're looking to get away from ASP.NET Web Forms, the I recommend ASP.NET MVC with a custom view engine (like Spark, or NHaml). This will give you the consolidation your looking for and allow you to avoid most of the Web Forms that your not happy with.
AFAIK, to do .NET web development, you are going to have to interact with ASP.NET in some form or another, but the custom view engines in MVC could be exactly the abstraction your looking for.
It is now possible to use a software stack completely separate to IIS and ASP.Net using Kyak, Nancy and Gate.
http://bvanderveen.com/a/gate-0.1.0/
You might want to check out Kayak, which is, to my knowledge, the only standalone .NET web development framework that's not ASP.NET.
Caveat: Kayak's request handling implementation is not the best, so there may be performance or scaling issues. I can't say for sure -- I've only read it, not run it.
Edit: I've taken another look at the source code, and it looks like they've rewritten a significant portion of their server code, and in doing so fixed the major issues. Performance probably won't be a problem.
MVC.NET is open source, so you can make it do what you want. It is a framework that is overrideable, extensible, etc. I'd look closer at it. It works great for me and I've come from a background of CGI, Struts and Webwork. I love it.
In my opinion nothing is more lightweight than the combination of NancyFX (http://nancyfx.org/) with Dapper (https://github.com/SamSaffron/dapper-dot-net) for data access.
NancyFX can be hosted within ASP.NET, WCF, Azure, OWIN-compatible environments, Umbraco or you can write your own host.
Read also these articles:
http://theothersideofcode.com/lightweight-development-in-dot-net-nancy
http://theothersideofcode.com/lightweight-data-access-in-dot-net-massive
I also suggest you to TinyIoC (https://github.com/grumpydev/TinyIoC) for decouple your application layers.
Regards,
Giacomo
You should look into the IHttpHandler and IHttpModule interfaces. These are the foundations for ASP.NET WebForms. Brad Wilson has a good intro to the former.
In the bad days when WebForms was the way to do ASP.NET development I was writing my own simple MVC framework with these interfaces. The bit I struggled with at the time was the View engine but now there are a number of these.
You take a closer look at ASP.NET MVC since the source is available and decide for yourself. It may be that you want to change some of the conventions used rather than the whole framework.
Is it a popular techinque to use the Model View Presenter (MVP) design pattern when creating Web Parts for SharePoint? It seems (to me) that this pattern is applied more often in the custom application space. So, if you have any thoughts on this, please share...
[Edit]
Perhaps the more important question is, if MVP is less popular in a SharePoint WebPart than in a custom application, why do you think this is (what factors contribute to this observation)?
It's probably not popular, but it's also probably a good design practice.
Perhaps the more important question
is, if MVP is less popular in a
SharePoint WebPart than in a custom
application, why do you think this is
(what factors contribute to this
observation)?
It is the "new" approach in the SharePoint world. Everyone is used to doing it the old SharePoint way. This is also true of ASP.NET and ASP.NET MVC.
MVC and MVP patterns are becoming more popular because they allow you to "decouple" the presentation layer from the underlying logic, essentially "uncomplicating" the UI.
Personally, I think anything that makes SharePoint an easier platform to program on is a welcome relief.
Because SharePoint is not compatible with ASP.NET MVC? It's planned somewhere down the line.. e.g. you're doing a lot of plumbing yourself before you can get any functionality going and I imagine out of all web parts created for SharePoint most will not be very complex because they are likely to be only a small part of the complete -SharePoint- solution.
Here is someone who built something like it, sort of: ARF
I have developed some webparts for SharePoint using MVP Pattern and I find it pretty good from the point of testability. However I discovered following problem:
If you have a webpart with custom EditorPart (the pane with custom properties) then the decoupling through MVP is not easily achievable, because the data from Toolpart is stored back to the WebPart.
Second thing: I do not think that the MVC pattern will be introduced into SharePoint soon (my oppinion I am not an insider), the impact would too big. However there exists an SharePointMVC
Framework. This has a rather big disadvantage that you have to create a seperate WebApplication for it.
I've found an article on this subject by a Microsoft employee, but has anyone implemented a more robust framework for this? Is there a lightweight framework for WinForms that could be ported easily? I'd like to get up to speed fairly quickly and avoid producing a framework/library of my own to handle this when someone smarter has already done this.
I haven't looked at the Mobile Software Factory from the P&P group, but I suspect it's kind of heavy. Is it worth a look?
Edit: I'm not looking for information on the ASP.NET MVC project. I'm asking about the compact framework 'WinForms' implementation, and how to implement MVC with that.
I personally think that the Mobile Software Factory doesn't hold much joy for CF.
We still use one part of it (EventBroker) at work and I'd like to even remove that part if possible (as it doesn't support generic events and you have to cast the arguments into their strong types from EventArgs). A sister project at work used it for part of their UI but had to rip it out due to performance issues (another big project, although that has additional performance issues of it's own as well).
The issue I find with the MVP framework that the P&P lib offers is that Forms and Controls OWN presenters instead of Presenters/Controllers owning Forms (who didn't read "It's just a view" : Pragmatic Programmer?).
This fits beautifully with MS's "Form First" rapid application development mantra but it sucks when you consider how expensive windows handles can be in CE (if you have a lot of them).
We run a very large CF application at work and we've rolled our own MVC framework. It's not hard to roll your own, just make sure you separate everything out into Controllers, Views, Business Objects and Services and have a UIController that controls the interactions between the controllers.
We actually go one step further and re-use forms/controls by using a Controller->View->Layout pattern.
The controller is the same as usual, the view is the object that customises a layout into a particular view and the layout is the actual UserControl. We then swap these in and out of a single Form. This reduces the amount of Windows Controls we use dramatically.
This + initialising all of the forms on start-up means that we eradicate the noticable pause that you get when creating new Windows Controls "on-demand".
Obviously it only really pays to do this kind of thing if you are rolling a large application. We have roughly 20 + different types of View which use in total about 7 different layouts. This hurts our initialisation routine (as we load the forms at start up) by a magnitude of about 10 seconds but psychologically most users are willing to accept such a hit at start up as opposed to noticeable pauses during run-time.
The main issue with the P&P library in my books is that it is a FF -> CF port and due to certain incompatability and performance differences between the two platforms you lose a lot of useful functionality.
Btw, this is by far and away the most comprehensive article i've ever read on MVC/MVP.
For Windows application (desktop or CE) I'd recommend using the Taligent Model-View-Presenter version without the interactions, commands and selections (e.g the controller/presenter performs all the work).
Neither of you (davidg or Kevin Pang) paid attention to the fact that he's interested in WinForms, not Web Forms. He wants a framework that pushes the Model-View-Controller design pattern (davidg, MVC isn't just the name of an ASP.NET framework) in a WinForms project using the .NET Compact Framework. He asked his question just fine.
There's also the OpenNETCF IoC framework (which I don't think existed when this question was asked) which is much lighter, but similar in object model to the P&P's Mobile Software Factory.
#DavidG and #KevenPang
MVC is not limited to a web technology, in fact the original smalltalk MVC was for desktop applications.
It works like this:
View = Client Form
Controller = Wraps up Client Events and marshals between View and Model
Model = Application Data and Business Logic
In pure Smalltalk MVC, the View is not limited to being a form, but can be any representation of Model Data...For example, if we had a Model that represented a spreadsheet, we could have the following views:
SpreadSheet View
Printer Friendly View
Icon View
etc, the Model would be the same, but the View would create a different output object in each case.
All that said, I don't know if such a framework exists for the .NET Compact framework, I just wanted to point out that MVC does not mean WebApp.
Take a look at mFly's Mobile MVC. I've never used it, but it's pitched as a reasonable MVC framework for the CF.
#davidg: "Why would you want MVC on Compact Framework?"
Why not? It's not like it's reserved for web dev, it's a pattern.
Edit: The above posters are correct. I saw MVC and immediately thought of web forms. My apologies. Feel free to disregard this. I'll leave my original message in place just in case anyone who is interested in web forms MVC needs the links. :-)
There are a couple MVC frameworks out there, neither of which are very "lightweight", but MVC is a pretty big shift away from web forms so that is expected:
ASP.NET MVC - This is Microsoft's attempt at an MVC framework. It is still in preview mode so use it at your own discretion, but several people are already using it in their production applications. You will find ample documentation on this with a simple Google search as it is becoming very popular amongst the .NET crowd.
Castle MonoRail - The MonoRail framework is an open-source MVC framework that has been around for quite some time and is in use on several production applications. It is definitely more flushed out than the ASP.NET MVC framework, but considering the amount of effort Microsoft is throwing at their MVC offering, I think will change relatively soon.