I need to re-write a businesss InfoPath / SharePoint application that has a fair bit of logic associated the operations a user performs - such as enable / disable controls; show / hide controls (complex tab controls); retrieve different data nad display differenty - as determined by user activity.
In trying to decide whether to use ASP.Net Web forms or ASP.Net MVC. As such I have been hunting around for a good realworld ASP.Net MVC sample business application (with Source code).
Does anyone know of anything that can demonstrate to me how to achieve the 'richness' of user interactions and responses in ASP.Net MVC that one can achieve using Web Forms?
I am know the Dinner Nerd application; and have checked out the offerings on CodePlex. So far most of the sample applications I have found do not have much of the complexity we have become used to dealing with in Web forms; and that I need to try and achieve. I posiibly have have to rethink the presentation & flow of the application in response to user actions in an MVC application (as compared to how one migh structure the flow in InfoPath / Winforms and Web forms). This might shift me more to what the existing sample applications might be indicating to me -'change the focus of the Views to be of presentational bias'. As such one would end up with many views each only permitting a reduced set of use interactions.
Thanks for any comments in advance.
Grant
There is exactly the same question asked here (ok, it is not about business apps) - Real World ASP.NET MVC Applications with Source Code?
just keep in mind that asp.net-mvc makes it really easy to write unit tests, which is the most important thing when coding applications.
If you have complex interaction scenarios you might be interested in performance too, asp-net.mvc performance is a way better...
Asp.net-mvc 2 (I haven't looked at 3 yet) makes the validation really easy and you can choose at which level you want it.
Related
I know the question is about solving the problem probably by different approach but let me specify in details what I want to ask and how much I understand about it.
We have two mvc approach used in ATG(or many other framework) pull based and push based.
As I understand it formhandlers and droplet both are playing the part of controller in different need, repositories are our model and jsps are providing views..
And if i am right till this point then what purpose the servlet chain is solving?How it fits into this picture of MVC?
Please If possible explain with the help of flow diagram from request to response (end to end).
Thanks a lot in advance to experts.
Please help.I could not find this kind of explanation anywhere.
The first thing to remember with ATG is that it is an old platform. So when trying to understand the different mechanisms through an MVC lens, remember that nothing was designed with MVC in mind-the platform predates widespread knowledge and acceptance of the MVC pattern in web development.
Droplets are a generalized mechanism for invoking Java code from a JSP (and previously, JHTML) template. The closest analogue in J2EE-land would be tag libraries. So you can use them to accomplish many different tasks. You can also use them as a poor man's MVC controller. This is done by coding a custom droplet class dedicated to handling the business logic of your page, and setting relevant page state as request parameters. Then you invoke the droplet as the first step in your JSP page. This is not very different from J2EE model 2 with the odd quirk that first your compiled JSP begins executing, then invokes your "controller" code and then resumes with processing the "view."
Form handlers, as the name indicates, are designed for processing form submissions. These are executed by a link in the servlet pipeline (DAFDropletEventServlet), before the page which was posted to begins rendering. Typical usage with form handlers is that they will send a redirect after executing, and cancel rendering of the page, which will abort any further processing by the servlet pipeline. Form handlers are the closest thing to a "controller" ATG provides. But they are awful for handling GET requests and result in some very unfortunate URLs when used for this purpose.
Why did they create two different mechanisms? Why have they not subsequently introduced an updated MVC model as part of the platform? These questions I cannot answer.
ATG, at the page rendering level, is not MVC. Don't look at it as MVC. ATG, at its core, is an extension of the basic Servlets API.
Forms and form-processing, with the successUrl and errorUrl is kind-of MVC. Droplets certainly are not.
It is perfectly acceptable in an ATG application to be fetching data as the page is rendering (i.e. Droplets)
I am developing the administration part of a site. It mostly consist of manipulating list of data such as:
Products
Suppliers
Tax profiles
...
I find the task of creating a controller that handle the CRUD operations of each model a little too repeating and prone to mistake from one controller to another.
I would still need to adapt some of these controller for additional operation, but not all.
Does someone know a proven approach for reducing the implication of controller for the usual CRUD operations?
One suggestion would be to look at tweaking the T4 template that is used to generate the scaffold methods. Check out Rob Conery's MVC Starter Site to see what he's done (look in /Web/CodeTemplates in the source for the general idea).
There are also some other MVC libraries out there such as FubuMVC that aim to cut down on code repetition, but it's not based on the actual ASP.NET MVC framework (and it's not really my thing).
How would I model a system that needs to be able to provide content in a format that would be consumable by iphone, Android or web browser (or whatever). All a new consumer would have to do is build a UI with rules on how to handle the data. I'm thinking something RESTful returning JSON or something.
I'm really looking for suggestions on the kinds of things I'd need to learn in order to be able to implement a system on this scale.
As an ASP.NET MVC developer, would that be the best framework/archetectrue to go with?
Thanks
I think you're on the right track with REST returning JSON. This is a format that's consumable by pretty much any language on any platform.
As an ASP.NET MVC developer, you should have no problems making a web service that's RESTful and passes data via JSON.
iPhone, Android, and modern web browsers such as Firefox, Opera, Safari, Chrome, have excellent Javascript implementations, splendid CSS, and reasonable subsets of HTML5 -- but you can't use either fact if you also want to support Internet Explorer or other old browsers. Fortunately, Javascript frameworks such as jQuery and dojo can compensate in good part for such issues (I personally prefer dojo, but jquery's more popular, and the choice between two such good frameworks is more of a matter of taste -- plus, there are advantages with going for the popular choice, such as, you can probably get better support on SO;-).
For REST returning JSON, just about any decent server-side arrangement will be fine, so, you may as well stick with what you know best, in your case ASP.NET MVC (just as I'd stick with Python and Werkzeug on App Engine, and people with other server-side preferences would stick with theirs -- ain't gonna matter much;-). Client-side, pick one of the two most popular frameworks, Jquery and Dojo, and go with it -- both have good books if that's your favorite style of study, but also good online resources. (Less-popular frameworks surely have a lot going for them as well, but there are risks in getting far away from popular choices;-).
As a general/philosophical approach, Thin Server Architecture is well worth a look (except for one detail: they used to recommend XML rather than JSON -- dunno if they've seen the light since, but JSON's clearly the right approach so ignore any suggestion to the contrary;-).
I am working on a project now that has to do this very thing. While searching the net on this I found Aleem Bawany's article on how it could be done in ASP.Net MVC. I really like the fact that it uses an action filter to handle the response. I modified the code in his article to look at the extension of the request instead of the content type.
For example /products/1.xml would return the xml representation of the
product whose id is 1 from the database.
Also /products/1.json would return the json representation of the product whose id is 1 from the database.
And /products/1 would return the html representation of the product whose id is 1 from the database.
The nice thing about returning data this way is that it lets the consumer decide how they want to consume the data.
I am working on a experimental website (which is accessible through web browser) that will act as a front-end to a restful interface (a sub-system). The website will serve as an interface between a user and the restful interface, as it will make http requests to the restful interface for almost all database operations. Authentication will probably be done using openid and authorization for the database operations will be done via oAuth.
Just out of curiousity, is this a feasible solution or I should develop two systems that accesses the database in parallel (i.e. the website has its own data access logic, and the restful interface has another data access logic)? And what are the pros/cons if I insist on doing it this way (it is just an experiment project for me to learn things like how OpenID and oAuth work in real life anyway) besides there will be more database queries and http requests generated for each transaction?
Your concept sounds quite feasible. I'd say that you'll get some fairly good wins out of this approach. For starters you'll get a large degree of code reuse since you'll be able to put other front ends on top of the RESTful service. Additionally, you'll be able to unit test this architecture with relative ease. Finally, you'll be able to give 3rd party developers access to the same API that you use (subject possibly to some restrictions) which will be a huge win when it comes to attracting customers and developers to your platform.
On the down side, depending on how you structure your back end you could run into the standard problem of granularity. Too much granularity and you'll end up making lots of connections for very little amounts of data. Too little and you'll get more data than you need in some cases. As for security, you should be able to lock down the back end so that requests can only be made under certain conditions: requests contain an authorization token, api key, etc.
Sounds good, but I'd recommend that you do this only if you plan to open up the restful API for other UI's to use, or simply to learn something cool. Support HTML XML and JSON for the interface.
Otherwise, use a great MVC framework instead (asp.net MVC, rails, cakephp). You'll end up with the same basic result but you'll be "strongerly" typed to the database.
with a modern javascript library your approach is quite straightforward.
ExtJS now has always had Ajax support, but it is now able to do this via a REST interface.
So, your ExtJS user interface components populate receive a URL. They populate themselves via a GET to the URL, and store update via POST to the URL.
This has worked really well on a project I'm currently working on. By applying RESTful principles there's an almost clinical separation between the front & backends - meaning it would be trivial undertaking to replace other. Plus, the API barely needs documenting, since it's an implementation of an existing mature standard.
Good luck,
Ian
woow! A question from 2009! And it's funny to read the answers. Many people seem to disagree with the web services approach and JS front end - which has nowadays become kind of standard, known as Single Page Applications..
I think the general approach you outline is quite feasible -- the main pro is flexibility, the main con is that it won't protect clueless users against their own ((expletive deleted)) abuses. As most users are likely to be clueless, this isn't feasible for mass consumption... but, it's fine for really leet users!-)
So to clarify, you want to have your web UI call into your web service, which in turn calls into the database?
This is exactly the path I took for a recent project and I think it was a mistake because you end up creating a lot of extra work. Here's why:
When you are coding your web service, you will create a library to wrap database calls, which is typical. No problem there.
But then when you code your web UI, you will end up creating another library to wrap calls into the REST interface... because otherwise it will get cumbersome making all the raw HTTP calls.
So you essentially created 2 data access libraries, one to wrap DB and the other to wrap the Web service calls. This basically doubles the amount of work you do, because for every operation on a resource, you will end up implementing in both libraries. This gets tiring real fast.
The simpler alternative is to create a single library that wraps access to the database, as before, then use that library from BOTH the web UI and web service.
This is assuming that your web UI and web service reside on the same network and both have direct access to the backend database server (which was the case for me). In this setup having both go directly to the database is also a lot more efficient then having the UI go through the web service.
Will be starting a web app that will have to provide many different HTML forms for data entry, so I was wondering if there is a web framework out there that does this in a clever way. generally when you have forms you have many considerations like navigation, validation, etc. that are not handled very efficiently by he frameworks I've seen so far.
Has someone taken the pain out of forms?
Have you tried looking at Grails? It can take your domain classes and dynamically scaffold them into web forms and apply server-side validation. The default scaffolding provides navigation, pagination, validation, and all kinds of other -ations that are pretty good!
Here's a good tutorial.
Try Qcodo.com, It is written in PHP (but fully OOP). It manages both database layer with nice Form templating system.
I think forms are handled pretty cleverly in Ruby on Rails. And also in .Net. The latter goes pretty far in letting you reuse the database logic for validating data and also has "automatic" handling of security issues like XSS and XSRF.