I'm a .Net desktop applications developer trying to switch to ASP.Net MVC (3 or 4 doesn't matter). We have a .Net library which notifies any GUI you want to put on this assembly by Property Changed Events (or any other custom event we deemed necessary for that matter).
This might not even be a relevant question, because perhaps it's done totally different in ASP.Net MVC, but how do you update your View in the browser on your client after receiving a Property Changed Event from an assembly on your server? We generate these events ourselves by the way. The assemblies are our own.
I've read about Partial Views, but I need to look into that. Whatever I came across seemed so cumbersome. Because it's really straight forward and simple in desktop development. So I'm starting to wonder if Property Changed Events are the way to go when developing for the web.
Thoughts? Links? Sources? I'm interested.
p.s.: See tags for a further understanding of what I'm going for.
HTTP world is entirely different
you request something from the server(Asp.Net MVC) and you get a response back from the server.
there is no way in which the server can contact the user back** as the asp.net server wouldnt keep anything in memory after the response
so here you are wrong in 2 aspects
1. property changes - because after the response there is nothing in the memory of the server there are no models(Objects) so there is nothing whoz property is actually changing
2. even if u maintaining something static if that changes there is no way for you to contact the client back
**there are some frameworks available that allow you to contact the client back and they do this by sockets or comet
You need to move away from the Event-driven thinking of desktop (and WebForms for that matter)-development.
MVC is a designpattern for separation of concerns, and no tightly bound events will exist, unless you do some hack-ish work of your own.
You can, however, accomplish this by using frameworks like SignalR that rely on Javascript and open connections, but the notion of events is not present in MVC.
Related
I have developed some MVC applications by using Entity Framework code first approach and now I am developing a new application that will also use web services for mobile applications that we will create. So, I have trouble about the issues below. Could you clarify me please one by one regarding to the issues?
Which web service technology should I use i.e. Web API, WCF, etc? (I am using MVC5 and EF version 6 in my project)
Can I use the same CRUD methods for my web application and for web services? If so, which modifications should be made on the methods and on the other fields i.e. models, etc?
For a current MVC application where EF code first approach was used, is it better to create a new methods for web services or should the current methods be updated by adding ability to support also web services?
Thanks in advance...
I highly recommend to use Commands and Queries. It's covered in this and this articles.
The Command is simple DTO object, and it could be easily sent over the network. In this case you have control over the fields and behaviour you want to make public.
Because commands are simple data containers without behavior, it is
very easy to serialize them (using the XmlSerializer for instance) or
send them over the wire (using WCF for instance), which makes it not
only easy to queue them for later processing, but ot also makes it
very easy to log them in an audit trail- yet another reason to
separate data and behavior. All these features can be added, without
changing a single line of code in the application (except perhaps a
line at the start-up of the application).
We are starting a major upgrade of a large WebForms application. The logic will be split between AngularJS on the front end and .NET MVC on the back end. What are the criteria about where to put routing? I can put it in RouteConfig.cs on the server and have .NET to be responsible for routing; or I can use ng-route on the client, and use only WebApi calls to the server.
I see pros and cons both ways, and I was wondering if anybody has any decision criteria. Or some articles that I missed (Google has plenty on implementing the routes; but not on the decision to pick one over another).
I would argue for full separation of concerns, so routing on the client. Doing the routing on the client puts the client in control of what is being displayed. The server would only serve the raw data via rest.
This also allows you more flexibility in the future as well. Say in 2 year you want to ditch Angular for the next new client framework. All you need are client developers to implement the UI calling the existing endpoints, the server code would not need to be touched. Want to move away from .NET backend? No problem, just implement the endpoint in the new framework, not client could would need to be changed.
You should use both as your application is large.
let say your screens are divide on the bases of rule.
When Admin will login you will load all files related to that functionality and after that take benefit of ng-view and make that functionality as a single page app.
So in this way you don't need to load all files once. by ng-view you can also share data between different screens.
I'm writting an application that has many Ajax widgets (Kendo-UI to be percise). It's starting to get messy to have all those Ajax responses without the standard controllers so I was starting to consider making each entities their own controller. If I'm taking the time to do this, I figured I might as well go foward and do those as WebAPIs since I was planning to do this in a not so close future, but hey, it would be done already...
So my question is: Is it a good practice to use an MVC application's own Web API as a Ajax Widget feeds or is there any reason to stick with standard Controllers?
I've seen some arguments about performance, but I don't think this applies to this situation. I believe it was more of a "Controller calling WebAPI" situation which has obvious performance hits. But since it's already a client side Ajax call, weither it goes into a standard MVC Controller or a WebAPI controller shouldn't change a thing, would it?
Edit
Additional information regarding the project:
I am using Entity Framework for the data access.
I have a repository pattern going on with UnitOfWork.
I am using proper a MVC structure (EF POCOs AutoMapped to DTO POCOs in the repository and fed into View Models by the controllers)
This is a MVC 4 project on .NET 4.0
There is a lot of database relationships (specially for the object I'm working with at the moment)
I don't know about "good practice", but it's certainly not "bad practice". I see no difference whether you do it in the app or a different one.
I think its a good thing but only if what you are doing in the API is kept as generic as possible to other applications and services can reuse the API.
Both the applications I have written and continue to maintain use pretty much the exact same stack as your app.
I have recently re-factored one of the applications to use the API for all the common things like lists that I'm binding to Kendo ComboBoxes etc. in my views. Its a fairly large application that re-uses a lot of the same lists such as states, priorities, complexities across various Entities and views so it makes sense to put those in the API.
I haven't gone as far as going the whole hog through. I draw the line with things like this:
public ActionResult GetAjaxProjectsList([DataSourceRequest]DataSourceRequest request)
{
return Json((DataSourceResult)GetProjectsList().ToDataSourceResult(request), JsonRequestBehavior.AllowGet);
}
That is very specific to how the Kendo Grid wants the data back. Nothing else I have connecting to this app will use this data in this format so I keep it in the controller.
In short... I use the API for common things within the same MVC app and things that I allow to be used by other applications or services, like Excel.
I got my datalayer, business layer ready. Now i want to to implement service layer.
I do not want to implement this layer in wcf ria services. Is there any other way to implement this layer in such a way using wcf, so that I get my model through wcf using js.
For example I have my domain 'Person'. (In domain project). Then in my 'PersonRespository' has
InsertPerson, GetPerson etc. to get and store the 'Person' in database.
Now I want to use asp.net mvc to show the person detais.
So next two layer will be Presentation Layer and service layer and manipulate data on client side using knockout.js and I am stuck on following issues.
Where will be mine Presentation layer will live. I am using asp.net mvc so It should be in model folder of mvc application, Is it wise to copy the same code class (Person) to model folder as well from domain model. Event when they are same.
How I will be able to get 'Person' model class in javascript and able to update it from javascript to database as well.
Is my architecture style is of enterprise level or i am missing something.
Any point to tutorial will be helpful.
If you have any further questions please let me know.
Thanks,
Daljit
Question 1:
No you should not be repeating your code. There is talk about this in the DRY (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) principals of development.
Question 2:
It is recommended that you serialize your model using a json serializer and send it to your UI. It will be updated etc, and then sent back to the services. Google MVVM pattern in javascript to see how this is done. KnockoutJs is a great start in achieving what you want. Its probably best to check out some examples done in knockoutjs to see what is going on. There are also many examples in MVVM for WPF that might help understanding the pattern at a higher level. I would recommend seeing codeproject.com for indepth MVVM examples.
As far as your layers go, you have many options, but a generic recommendation would be:
1) Presentation must be triggered through MVVM bindings, ie if the binding updates, the UI will then update itself.
2) the asp.net side of things should only update the models when sending updates via ajax to the UI. (not everything needs to be sent via ajax, im not saying that. When it does, it shouldn't also send extra html or js to put in the page).
3) Your models should really come from asp.net to the html page. (this will make things easier later, as the page will only be updated via asp.net models and you won't get items coming from multiple domains, which ends up being a nuisance.
4) Your asp.net site should provide a wrapper for your WCF service, and can foward calls to WCF.
OR
If you didn't want to wrap WCF with asp.net and needed your UI to communicate directly via ajax to WCF (should be a rarer usecase like doing an igoogle like page with widgets, or maybe mobile development with no asp.net interaction, ie full js app) Then you can investigate CORS as an option to go from JS to WCF and JS to asp.net (This is of a hard difficulty, easy to program, hard to get working for WCF as there is very very low documentation on it for in my case non IIS hosted WCF). See this page for information: http://enable-cors.org/
It seems to me that, for structured development with both depth and breadth of capability, ASP.NET MVC and Silverlight have the potential to make a nice powerful framework with superior UI granularity and reduced AJAX exposure. Have any of you tried building such a stack with future durability in mind?
ASP.NET MVC and silverlight?
In some ways, it is an either-or choice - your data is displayed either in html/css/js generated by ASP.NET, or in Silverlight. Why mix them? I'm sure that ASP.NET MVC is a good way to deliver Silverlight, but that doesn't necessarily make it part of the same UI.
It's generally about reach vs. richness. A web UI with no Silverlight or Flash can reach more users, but one with Silverlight can have a richer UI. Silverlight is good fun to code in, and I have seen some wonderful apps using Silverlight's streaming video features, but if e.g. you are doing data entry and display, and you don't need the richness of Silverlight, then why not keep the reach and stay in Asp.Net?
If you are going to do the UI in silverlight it makes sense to do all of it in Silverlight. I have had good experiences with all the ViewModel-view-controller page flow happening inside the Silverlight app, rather than transitioning to another html page and loading a different silverlight app. It's faster and you can do fancy transition or fade-in effects in Silverlight's XAML markup.
Why is "reduced AJAX exposure" a desirable goal? Sites like e.g. Stackoverflow here use AJAX techniques to very good effect.
Stephen Walther's talk at MIX09 shows four pillars of ASP.Net as it currently stands - Forms, MVC, AJAX and Dynamic data. A lot of people are Seeing it as "moving from forms to MVC" but there are other approaches also being developed in the mix.
I've built a little test app with SL and MVC. It didn't work that well but I don't think I was doing right. I've tried using SL in views but its slow to switch pages since its loading new SL instances all the time. I've tried a single SL app which meant it contained all the control code as well but that relegates the server to data access which only needs some WCF/Web service code no need for MVC there.
It may work better if we dispense with the idea of there being many view pages. In my next iteration I shall be using controllers to respond with XML or JSON directly to requests from a Silverlight app which contains the views. However this approach would still leave some questions unanswered, for example, how does the controller get to have a say in what view is actually displayed?
To be honest, I'm getting the feeling that SL to ASP.NET-MVC are yet shaping up as a good match. Some web apps may benefit from some SL elements (charting for example) yet the app remain firmly in HTML. On the other hand, an app whose UI is purely in SL (whilst internally using some similar View/Controller concept) doesn't really need MVC on the server-side.
Its early days, it will take while for us early adopters to see what really works and what doesn't. There being a beta for version 3 with more coming from MS in the way SL can access serverside data may change things further.
I asked a similar question here: Does Silverlight 3 Change the MVC vs. Silverlight question. This was in response to SL2 vs. MVC where folks all agreed that they were complimentary technologies. I'm still not convinced. My experience has been similar to AnthonyWJones. Per the previous posts, I tried to mingle them without a lot of success. Could be my own ignorance, though. Right now I'm building a Silverlight only application using SL3 beta. I seem to be a lot closer to my intended effect. That being, an application with a few database features. So it didn't make sense to build a completely stand alone app (since the data is central), but I really wanted some Silverlight goodness to render the end result and allow the user to interact.
So where in the hell am I going with all of this? Based on my experience, this still seems like a YMMV type question. It really depends on what you're trying to build. Since I'm light on database, heavy on interaction, I'm biting the bullet with Silverlight 3 and .NET RIA Services for the little database stuff. If I were writing Stackoverflow, I'd probably do ASP.NET MVC and AJAX.
We are currently using ASP.NET MVC as an alternative to WCF to expose data to Silverlight where our Silverlight app makes RESTFUL calls to urls in our Mvc application and the controller returns a JsonResult which works well for us. It's by no means necessarily the text book way but we found this way the two technologies compliment each other. Now if we ever need an HTML implementation we've already done the Model-Controller work which can be re-used.