Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have a solution that is consists of 3 projects.
I have attached picture here.
First project is with SSIS.
Second is SSRS
Third is MVC5.
I want to have one page in MVC project that can show the task in Data import. I want to have one page in MVC project that first list all the reports and then you can run any report by clicking on it. I am not sure how to do that. All the examples I have found showed creating asp form to do so. Can someone point me into right direction?
Out of the box you are not going to find a great deal of support for MVC applications using the traditional SSRS ReportViewer control. Some companies, like Telerik, have created ReportViewer controls that fully support MVC applications.
You can add support for the WebForms in an MVC application in order to support the ReportViewer control, however, you are going to be firing up both the traditional asp.net webforms and asp.net mvc processing in your app. There are also some caveats that you will have to look into such as support for partial postbacks for sorting, filtering and other interactive features the web forms viewer supports.
One other option would be to create your own viewer and request the reports via the ReportExecution2005 api. If you render the report as HTML you can simply insert the render output into a container in your application. With the api you can perform any task the ssrs manager performs as it uses the same api, including:
Get a list of all cataloged items including reports
Render reports as PDF, HTML, EXCEL BYTE[], etc.
One caveat to using the api is that you will have to respond to and proxy much of the interactivity back to ssrs in the form of another report request, i.e parameter changes, sorting and paging.
I used the following and it worked like a charm in MVC 5.
https://reportviewerformvc.codeplex.com/wikipage?title=Getting%20Started
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have developed applications using .net MVC with razor view engine.
Recently I was going through knockoutjs being used for MVC applications.
From a 10000 feet bird's eye view , I see that both the approaches have the similar two way binding mechanism .
In the first approach razor syntax for binding the model and in the second we use the knockout data-bind attributes.
My understanding is , why is it that many people are nowadays preferring Knockout and all the buzz recently . Is there any major advantage of replacing razor syntax over knockout library?
They have nothing to do with each other.
ASP.NET MVC
As its name says, it uses MVC (model view controller) technology. That means that you have a model (all the business logic), that can be used to create view models to render the views (by using the razor template). The browser can post data to the controller, and the controller will usually answer by creating a new view model to render a new view, and send it as response to the browser.
So this technology basically uses the browser to send GET or POST requests to the server, and the server answers with rendered views. It can do it directly, or using AJAX. (ASP.NET MVC is much more versatile and can do much more than rendering views, but this is the basic idea).
So ASP.NET MVC involves the server in all operations: it must instance and use a controller, execute an action and send its result as response to the browser.
Knockout
This technology is completely different, in several regards:
it uses MVVM, which consist in a double-way binding between a view (HTML) and a model (JavaScript object). A change in any of the ends is applied automatically on the other end.
it happens on the client side, without using or depending on server resources (as far as it concerns Knockout)
it usually doesn't involve heavy business logic, but simple view models that can show and get data from the user.
This is all what Knockout can do for you. If you need to involve the server, and "heavy" business logic, you need to communicate with the server by sending and receiving objects, which you usually do in JSON format by exposing Web API services. (These services are usually implemented with ASP.NET Web API, but can also be implemented with ASP.NET MVC actions with JSON results, which it's a worse option).
Conclusions
So ASP.NET MVC involves the continuous use of controllers and communication between browser and server, while Knockout is a pure client side technology that doesn't need the server at all. Naturally, to make a Knockout application useful you usually communicate it with the server.
OTOH, Knockout allows to create a Single Page Application, which is a JavaScript application that can run by itself, without loading new full pages from the server, and which usually communicates with services, in the form of Web APIs. One advantage of this is that the application can work even without a server on the other side, and is much more responsive, because it doesn't depend on comminucating with a server to refresh the view.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been using MVC for over a year now, and I like it alot. I've heard of Knockout.js. How is the comparison between these two? Which is better?
MVC seems to have reached its maturity with MVC5, with alot of support.
I do not see knockout.js as well supported. There examples on their site do not even work in Firefox. However, I can see the potential of this since it is written in javascript, client-side, and possibly faster since its client-side, like ajax.
What are the advantages of Model-view-controller vs Model-View-View-Controller?
You should not be comparing Knockout.js to Asp.NET MVC. The only similarities are that they both use the same Model-View-Controller pattern.
Knockout.js:
Knockout is a standalone JavaScript implementation of the Model-View-ViewModel pattern with templates. The underlying principles are therefore:
a clear separation between domain data, view components and data to be displayed
the presence of a clearly defined layer of specialized code to manage the relationships between the view components
The latter leverages the native event management features of the JavaScript language.
Asp.NET MVC:
ASP.NET MVC allows you to build a web application as a composition of three roles: Model, View and Controller.
A model represents the state of a particular aspect of the application. A controller handles interactions and updates the model to reflect a change in state of the application, and then passes information to the view. A view accepts necessary information from the controller and renders a user interface to display that information.
As you can see Knockout.js is an MVC implementation for JavaScript while Asp.Net MVC is an MVC implementation for a complete web application from front end to server. These technologies can even (and very often) be used together to build well structured applications on both the front end and the back end.
You are comparing apples and oranges...
Since you are now familiar with ASP.Net MVC (and the MVC design pattern in general), it is time to take the next step and use a JavaScript MVC framework WITH it.
There are many choices, some popular ones include Knockout.js, AngularJS, Backbone.js, Ember.js, and many more. The site TodoMVC will give you a flavor of what is out there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've been in some discussions lately and the talk is about moving over to ASP.NET MVC and Knockout for future work on a product that is currently ASP.NET web forms. This product has many of the characteristics of the general current definition of a SPA.
I've never quite seen how MVC actually fits in when you start generating all your views with JS view models which get their data from calls to JSON web services.
Is there a "sweet spot" that leverages the best parts of Knockout w/JS models and JSON and the MVC framework?
Here are some things that I've been thinking about this (a little random - just seeing if I can spur on some discussion/answers):
When would you use Knockout vs. Razor? Knockout generates the view elements at run time on the client browser. Razor runs as part of the server request before the client receives the response. Are there times that one is clearly better than the other or does it come down to personal taste?
Is there value in keeping more code under the guise of C#/Razor for the purpose of code completion? Also, when exceptions get thrown, stack tracing to compiled code seems easier than JS debugging.
Is it better to completely separate the view from the back-end by creating a blank ASP.NET application and an independent Web API project?
Lots of great questions, I'll share some of my thoughts on the subjects. (Questions have been paraphrased):
1) Is there a place for MVC in a Knockout world? - Absolutely. MVC is a lot more than just Razor. Server side routing, Areas, Authentication, and more, are all provided by MVC. So in my mind, I can still use MVC for all the "admin and organization" but still have all my Views be primarily (but not necessarily completely) AJAX driven. I have discussed using MVC and KO together on SO before. I also have a video dedicated to that topic at WintellectNOW dot com.
2) When should I use Razor? - Let's actually switch up the terminology. It really isn't about Razor vs. Knockout: it's really about server-side vs. client-side rendering.
So when should you use server-side rendering? One ideal time for this is when you are loading data that only has to be done once when the page is initialized. For example, if you have a list of States for a drop down, and that list is extremely unlikely to change, go ahead and load that on the server side. Why turn around and make another request back to an API in that case? I would reserve those calls for dynamic or context sensitive data.
3) Is there value in keeping more code in C# for tooling purposes? - IMHO, no. It's true that debugging JS can be painful, but that is not enough justification for me to disregard all the awesome things I can do client side. It's worth the occasional frustration to provide a better user experience.
4) Should I move Web API to a different project to keep the code separate. - It completely depends on the needs of the project. If the Web API project is going to service multiple applications, then YES it should be in a separate project. That will also put it on a separate DOMAIN, SUB, PORT, or something to differentiate it from the rest of the Web app. Doing so introduces Cross Origin Resources Sharing (CORS) issues. CORS is a particular hell I wouldn't go through unless absolutely necessary. If your Web API is only going to service your single web app, do yourself a favor and keep it in the same project.
As with everything else, a lot of this comes down to personal preference. Mine is to use Server side for managing the bigger picture of my app, and client side for all the UI/UX.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I understand that stackoverflow uses Linq to SQL. I decided that since stackoverflow uses linq to sql (and in my opinion works well in a high traffic site), that I would continue using it in my MVC 4 application.
What I have thus far in my solution is an MVC 4 internet project, an web api project, model class library, used to override some of the mapping in linq to sql, and then my linq to sql library project.
I noticed when I added a web api project to the solution, the api project also had views, controllers etc. as the regular mvc 4 project.
Does the web api project provide the same abilities for views etc, as MVC 4 web project?
What would you recommend for project settings...
Eliminate the mvc 4 internet project and just use the web api.
Eliminate the web api and use a repository?
Use both the mvc 4 internet project and the web api?
Or ????? and why?
I am moving an asp.net web forms application over to mvc. Since stackoverflow uses linq to sql I decided re-use my linq to sql library instead of creating linq to entities.
All data access and manipulation is done using linq to sql, so it's a lot easier for me to just move the queries over to the web api.
I want to re-use as much code as possible and will be using Telerik's Kendo UI for MVC.
The application will need to work both on-line and offline, so I thought the api would be good.
But after noticing that the api contains the same object types as the mvc internet project, I didn't see why I would use both the internet and api mvc projects.
Thanks
You can go both ways. If you create a Web API project, it comes with all MVC4 features. In the controllers folder project, if you right click and say new, you have the option to create a Web API controller or an MVC controller. Since both have different URLs(Web APi will have /api/ in the url by default), you can decide whether to call MVC4 controller or Web API controller.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I started building an asp.net webform application. Gradually, I moved all the presentation logic to javascript. I removed all the postbacks and replaced those with calls to web services that receive, process and return json data. I use javascript to generate HTML based on the json I receive from my web services: no gridview to generate tables, everything is generated on the page.
I'm at the point where the aspx pages don't have any code behind any more. I moved all the logic into code libraries in my AppCode folder. I'm not using the viewstate. I'm left with a master page that uses several literals to inject user data on load; the master page has some code behind to manage this process. The main webform functionality I'm using is membership management: I have one login page and one button on the master page that triggers the log out on postback.
Eventually, the entire front-end will work as a one-page application.
How far am I from having an MVC application? Should I keep the structure of my application as is or is there going to be a benefit to moving to an MVC app?
The main difference between WebForms and MVC in easy terms: in WebForms you essentially call a view ("MyPage.aspx") which has some additional logic/code attached to it. In MVC you call a remote function (action) like "products/detail" which contains logic and decides what to return to the browser (for example a view, but it could be json, javascript or whatever). So according to your description, those "remote methods" would conceptually work well as an alternative to your web services.
But as you're using the web forms part only for rendering the initial web page and use web services for all the rest, I doubt that there wouldn't be that much benefit from moving to MVC now. The new WebAPI could be interesting for you, but if you already have your services in place I don't know if you should move now.
Membership isn't any different between WebForms and MVC, so there's no need to change anything here.
I'd say: if your current design works, leave it at that for now.