I've been tasked with checking if the domain controller for a C# MVC web portal has been hard-coded, and if it has, update it. I have access to the source but I can't seem to locate where the domain controller is defined.
I'm wondering where the domain controller is usually set up in an MVC project (in a config file or within a controller class) or at least what the code would look like.
Any advice would be helpful.
It depends. How would a domain controller be used? Is the site using Windows authentication? Is it accessing Active Directory for some other purpose?
Regardless, the easiest way would likely be to get a list of all your domain controllers (if you have one domain, there likely isn't that many) and do a solution-wide search for each.
I'm about to start a new project in ASP.NET MVC5, which has a bit of Web API too. I'll also need a Windows Forms client which will call the API. This client has a file system watcher that detects when a file has been changed, and will post the contents to the API.
When the API receives the data, it does some calculations, and ideally will send the results through SignalR to the browser and update the display.
I'm getting rather stuck trying to work out the authentication. I want to use Individual User Accounts, so the user can log in with the Windows Forms client (and get a token) and in the browser to view the data.
I've got as far as File -> New -> Project, and tried an MVC project with the Web API box checked, and a Web API with the MVC box checked. Looking at the two AccountController classes that these generate, they seem quite different.
I guess the options are
Try to get these two controllers working together
Call the MVC controller from the Windows Forms client
Have two projects in the solution and try to work out how to use SignalR to talk between them.
A better way?
I suspect the last one. I've not used Web API before, so I could be doing this all wrong. What approach should I take?
I would say, create 2 different projects, 1 for MVC 1 for API.
Use 1 BLL which is referenced in both of them and carries the logic for both of them and will not be dealing with separate controllers.
Of course if you need other layers like DataAccess or Repository, you have to create them once and they will be referenced in the BLL which is later referenced in both MVC and API interfaces.
I am creating a new MVC4 project, and research has lead me to believe that communicating from javascript to the server side is better achieved now through web API framework rather than controller actions. Is my understanding correct on this?
I am presuming that I can share all my attributes etc between web API and MVC controllers so on the face it, it does not seem a massive change for me.
When I am setting up applications, I like to split components out in to projects. My plan was to have a MVC project and a web API project. But I have ran in to issues. For example I have ended up with 2 apps as such, separate routing set up etc etc.
So my question is, in a MVC application should the web API framework sit within the same project, or should the web API be separated into a project of its own and work around the issues?
Unfortunately you are wrong about that - I am presuming that I can share all my attributes etc between web api and mvc controllers so on the face it, it does not seem a massive change for me.
Many of the concepts used by Web API and MVC, even though similar at first glance, are actually not compatible. For example, Web API attributes are System.Web.Http.Filters.Filter and MVC attributes are System.Web.Mvc.Filter - and they are not interchangeable.
Same applies to many other concepts - model binding (completely different mechanisms), routes (Web API uses HTTPRoutes not Routes, even though they both operate on the same underlying RouteTable), dependency resolver (not compatible) and more - even though similar on the surface, are very different in practice. Moreover, Web API does not have a concept of areas.
Ultimately, if all you are trying to do achieve is to have a "new, trendy" way of serving up JSON content - think twice before going down that path. I certainly wouldn't recommend refactoring any existing code unless you are really looking into embracing HTTP and building your app in a RESTful way.
It all really depends on what you are building. If you are starting a new project, and all you need is to serve up some JSON to facilitate your web app - provided you willing to live with some potentially duplicate code (like the stuff I mentioned above), Web API could easily be hosted within the same project as ASP.NET MVC.
I would only separate Web API into a separate project if you are going to build a proper API for your online service - perhaps to be consumed by external customers, or by various devices - such as fueling your mobile apps.
IMO, security and deployment should drive your decision. E.g., if your MVC app uses Forms authentication but you're interested in using Basic authentication (with SSL) for your API, separate projects are going to make your life easier. If you want to host yout site at www.example.com but host your API as api.example.com (vs. www.example.com/api), separate projects will make your life easier. If you separate your projects and subdomain them accordingly and you intend to leverage your own API from your MVC app, you will have to figure out how to deal with the Same Origin Policy issue for client-side calls to your API. Common solutions to this are to leverage jsonp or CORS (preferably if you can).
Update (3/26/2013): Official CORS support is coming: http://aspnetwebstack.codeplex.com/wikipage?title=CORS%20support%20for%20ASP.NET%20Web%20API
After some degree of experience (creating API for apps and for mvc). I mostly do both.
I create a separate project for api calls that come from other clients or other devices (Android/IOS apps). One of the reasons is because the authentication is different, it is token based (to keep it stateless). I do not want to mix this within my MVC application.
For my javascript/jquery api calls to my mvc application, I like to keep things simple so I include a web api inside my MVC application. I do not intend to have token based authentication with my javascript api calls, because hey, it's in the same application. I can just use [authorize] attribute on a API endpoint, when a user is not logged in, he will not get the data.
Furthermore, when dealing with shopping carts and you want to store a users shopping cart in a session (while not logged in), you need to have this in your API as well if you add/delete products via your javascript code. This will make your API stateful for sure, but will also reduce the complexity in your MVC-API.
Steven from SimpleInjector (IoC framework) advises two separate projects: What is the difference between DependencyResolver.SetResolver and HttpConfiguration.DependencyResolver in WebAPI
I have recently done almost the same thing: I started with a new MVC 4 web application project choosing the Web API template in VS2012.
This will create a Web API hosted in the same application as MVC.
I wanted to move the ApiControllers into a separate class library project. This was fairly easy but the solution was a bit hidden.
In AssemblyInfo.cs of the MVC 4 project add similar line of code
[assembly: PreApplicationStartMethod(typeof(LibraryRegistrator), "Register")]
Now you need the class LibraryRegistrator (feel free to name it whatever)
public class LibraryRegistrator
{
public static void Register()
{
BuildManager.AddReferencedAssembly(Assembly.LoadFrom(HostingEnvironment.MapPath("~/bin/yourown.dll")));
}
}
In the MVC 4 project also add reference to the Api library.
Now you can add Api controllers to your own separate class library (yourown.dll).
Even if your project is so complex as to warrant two "front ends" then I would still only consider splitting out webapi into a separate project as a last resort. You will have deployment headaches and it would be difficult for a newbie to understand the structure of your solution. Not to mention routing issues.
I would aim to keep the system.web namespace isolated in the one "presentation layer". Despite the webapi not being presentational it is still part of the interface of your application. As long as you keep the logic in your domain and not your controllers you should not run into too many problems. Also, don't forget to make use of Areas.
In addition to setup the separate DLL for the Web.Api.
Just a Suggestion:
Create the Project
Nugget WebActivatorEx
Create a a class Method to be called upon app_start
[assembly: WebActivatorEx.PostApplicationStartMethod(typeof(API.AppWebActivator),"Start")]
[assembly:WebActivatorEx.ApplicationShutdownMethod(typeof(API.AppWebActivator), "Shutdown")]
Register a web.api routes inside the Start Method
public static void Start() {
GlobalConfiguration.Configure(WebApiConfig.Register);
}
Reference the Project to the Web Project. to activate the Start Method.
Hope this helps.
I tried to split the API controllers into a new project. All I've done is to create a new library project, moved the controllers inside folder named API.
Then added the reference of the library project to the MVC project.
The webAPI configuration is left in the MVC project itself. It works fine.
I am new to MVC and Web Services.
According to my project, I have to show listing data at ViewLayer.
The listing data which I have to show will come from other region via its web service server.
It means that I have to communicate with these web server which is separate with my web application server.
Moreover, my web application have to update some of the data and send this updated data to there web service server again.
That is my project requirement.
So I have searched every possible solutions. Then I found one at stackoverflow.com. According to this, I found that I need to use $.ajax { url: ... } style which I think I need to fully rely on view layer.
Then I had found another solutions which I think I need to fully rely on Controller Layer. I mean I have to write all the code which need to talke with web services only at controller layer.
As I am junior to MVC, I could not decide which one is suitable for me.
Every suggestion will be really appreciated and welcome your any suitable solutions more.
As with all things development - it depends!
If you own the services, they hang off of the same domain, and you're mostly focused on rendering the results of the web service call to HTML, the client-side AJAX calls work well.
If they're on a different domain (or even subdomain), or you want to do more than "just call" the service (e.g., clean up the response, add some tracking, transform it in some way) then handling the web service call via the controller is probably the way to go. You can also easily add server-side caching and logging with this option.
You could use the Unobtrusive Ajax Helpers in MVC3
http://bradwilson.typepad.com/blog/2010/10/mvc3-unobtrusive-ajax.html
So I have been working on a small web application (site) for a group of friends of mine and have come to the realization that things need to change. The application has two faces to it
a public facing side that serves dynamic data to visitors and non admins, and
an admin side where admins can update or create the dynamic data to be served.
This application started off as a single webforms project sectioned off by separate pages and and web.config security of folders. Then it grew into separate projects (MVC admin side and webforms front end). I later had to bring it to where it is today, a single web app with a mix of MVC (admin) and webforms (public), due to deployment issues.
Now I am looking at migrating it to a single MVC project. I would like to keep my administration functions desperate from my public facing side by URL like /Admin and am not sure how to do it. I have read a lot of topics on grouping controllers into modules but am not sure that is the right thing yet.
Should I just create admin functions inline with the rest of the public app and determine if the user is logged in or not?
Or should I create Admin controllers that are separate from the public controllers (EventAdminController vs CalendarController)?
What have others done?
Suggestions welcome, thanks stackoverflow.
Yes I am using the ASP.Net MVC framework from Microsoft. Darryl, are you saying to place my views in an Admin folder and protect that it using a web.config (to check security and roles) or to place my controllers in an Admin folder?
My assumptions was that you were saying to place the controllers in an Admin folder, say under controllers. This would still mean that HomeController in /Controllers is different than HomeAdminController in /Controllers/Admin. In this case you could configure specific routes for each but I don't see how simply putting a controller in a different folder would protect them (unless using the Authorize attribute on actions).
As for placing the views in a different folder, I can see how that could work in theory. But wouldn't the controller (in theory without any authorize attributes) still execute up to the point that the view is returned? I would then either expect a redirect or an error. Either way I wouldn't want to execute my controller action if you can't get to the view, and would rather not do any internal action pre-checking.
We have a similar problem where we are creating a very large ASP.NET MVC application and to separate functionality into areas we are using a process very similar to this post by Phil Haack. By creating areas you can have unique controller names for each area instead for the whole application, you can separate your modules far more easily and you can share authentication and basic common functionality.
On a MVC project I am working on I put all the admin stuff in an admin folder. To see the admin folder you must be authenticated and in the correct role. My controllers tend to be very minimal, most logic is in a business layer that the controllers use.