I have MVC application in which the controller sends out emails based on trigger actions on the view. This works correctly. The project also has a business layer dll which is use to interact with the SQL server database. This works correctly. It is now come to my attention that a website under construction needs to access the controller dll to send emails. Right now the website only works with the BLL. With the data objects being different between the website an the application, how do utilize the same code so that both projects can send emails? I am using Razor templates to create the emails, if that makes a difference.
Upgrade to at least MVC 4 and start utilizing the Web API capability to offer a web service to the other application in development.
Here is a good starting blog post
Related
I have a silverlight application which accesses its data through RIA Services, from a WCF app in the server. The current structure looks like this:
DataWebServer - A Web application project, which holds the .aspx page that will call the Silverlight components, the .edmx model file and a MyService class, inheriting from LinqToEntitiesDomainService<FortWayneDB>.
Silverlight App - Contains .xaml e .cs files that will generate the .xap binary files, hosted by the WebServer. It access "DatawebServer" project through RIA Services.
It's all working fine, but now I need to create a new application, and since we will going to need it to run on platforms like tablets and smartphones, we decided to build it in HTML5, instead of Silverlight.
How can I make this new WebApp to access the data entities on "DataWebServer" project?
I think of 3 different solutions, but I'd prefer the third one, which exactly my question.
I could place the new WebApp in a folder in the same webprojeect "DataWebServer", but that wouldn't be very organized, I'd rather separate this app from the "DataWebServer".
The second alternative, which I will follow in case I can't succeed with the third, is to create WebMethods in "DataWebServer" to be accessed from my new WebApp.
the third, which I don't know how to do, is to make my new Web App to access the Entities through RIA Services, in the same way the Silverlight Client does. I've searched the Internet, but all articles I've found show how to access RIA Services from the same project. Does anyone know how I can do that?
The first method is the most sensible.
From your details, I assume the DataWebServer is "publicly" accessible; at least as much as your WebApp would be. There is little value in having WebApp data requests go to a different server, DataWebServer, as this introduces an unnecessary delay while one web server calls another. Instead of re-using the HTTP services from DataWebServer, add the WebApp functionality to the DataWebServer and re-use the LinqToEntities context.
If you desperately want the third option, you should consider creating your WebApp in a way that the JavaScript in the app calls the DataWebServer for data from the client's browser. Importantly, this approach avoids WebApp web server calling to DataWebServer for data.
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'm just starting a project where I would like to use Kendo UI (based on jquery) with C#. A few weeks ago I was successful in handling requests using Web Services (asmx), was pleased with the results and performance, and was able to create forms quickly.
Since this is a new project, I thought I could look into different concepts such as MVC and WebApi. I found MVC to be the most complicaded so I went for WebApi and started playing with controllers and requests. So far what I'm finding (don't judge me, I'm new to these new concepts), is that Web Service seems to be simpler and more flexible.
So I guess what I'm looking for is... what are the main advantages of using MVC vs WebApi and even vs Web Services. Are there any downsides to Web Services? Would it be a bad practice to have my data layer controlled by Entity Framework, all models defined, and my requests handled by Web Services?
Any clarifications are welcome. Thank you.
In a broader sense, Web API is used to create Web Services ! It uses HTTP as its standard for creating services (instead of SOAP like in asmx) as its more open and any type of client like a mobile app, desktop app, web app etc will understand HTTP protocol. Another advantage is that u can easily use JavaScript/jQuery to communicate with your Web API. With SOAP web services, its a nightmare!
Kendo UI and Web API is a great combination. We have recently created a mobile iPad app using this combination and it worked like a charm. We also used Entity Framework with oracle as back end DB and it never gave any issues.
Webservices are nice if you have the need for it. A need as in needing that logic/data in more than one different type of application (such as web, and a mobile app, and a desktop app). (Or if you want to sell the service you're providing)
Using a webservice for ONLY a website which you don't except to expand to other things is complete overkill.
Furthermore, the MVC framework and the Web Api framework are pretty similar except web api is used exclusively for webservices. Coding in both of them will be the difference between white bread and wheat bread.
After searching the entire day about what I should use, I'm not sure what option would be best for my needs so I hope someone with more experience could help me out.
I have a winforms application (c#) and a ASP.NET MVC 4 web application (c#).
I wish to connect these, the goal is to send and receive data from the database which I use in the MVC 4 project, but from within the windows forms application. The data I send from the windows forms application to the database, is then used by the MVC 4 web application.
I am entirely new to web services / Web Api's so I can't really decide what option would be best. Any help would be much appreciated..
If you already created MVC4 project then you can add actions to any controller
and return JSON data like below :
public JsonResult GetCategoryList()
{
var list = //return list
return Json(list, JsonRequestBehavior.AllowGet);
}
or you can create new project of MVC4 and select WEBAPI template . It will create webapi project for you .It will create with example .so it will easy for to create webapi.In webapi it return data automatically convert to xml and json as per request
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web AP -> ASP.NET Web API
Service -> Web API controller
Operation -> Action
Service contract -> Not applicable
Endpoint -> Not applicable
URI templates -> ASP.NET Routing
Message handlers -> Same
Formatters -> Same
Operation handlers -> Filters, model binders
Other Links
If you have an MVC 4 App already, it would be better to use Web API (RESTful service)
I assume you have some knowledge in building REST API (understanding of POST, PUT, UPDATE stuff)
It is simple in configuration and usage. All what you need actually is to create a new controller like:
class MyApiController: ApiController {
public Post(SomeClass item) {
....connect to db and do whatever you need with the data
}
}
You'll also should configure routing for Api.
And then in your winForms app you can simply use HttpClient class to perform api call.
HttpClient aClient = new HttpClient();
// Uri is where we are posting to:
Uri theUri = new Uri("https://mysite.com/api/MyApi");
// use the Http client to POST some content ( ‘theContent’ not yet defined).
aClient.PostAsync(theUri, new SomeClass());
Take a look at some implementation details right here:
Web Api Getting Started
Get started with WCF is not so easy as with Web API.
Given the tags you've used, my guess is that you're deciding between SOAP Web Services and WCF. Given these two, I say to go WCF. SOAP web services (as implemented in Visual Studio) are the older technology; still serviceable, but WCF can do everything an older SOAP service can do (including look exactly like a SOAP service) and more.
If you have a web service that connects your web server to your database server (these two things should be on different machines; your web server is exposed to the world by necessity, while your DB server should be locked down like Fort Knox), I see no reason why you shouldn't use that same service as-is for an internal WinForms application (using a LAN/VPN to access the service layer on the DB server). For a WinForms application that must access the data over the Internet, I would recommend reimplementing the service as a WCF service supporting secure encrypted data transfer. You can also set up the service endpoint to only accept HTTPS connections, and thus simply run your existing service through SSL/TLS.
What you choose will primarily depend on how much time-resources you can commit to resolving the problem; moving to HTTPS is a fast fix requiring little if any code changes, while reimplementing in WCF will take more time but will allow additional security measures beyond a simple secure tunnel.
Or something lightweight like Nancy: http://nancyfx.org/
We had some issues with MVC4 WebApi stuff and ended up using ServiceStack on the server side JavaScript/AJAX for web clients and RestSharp for thick clients.
One of our specific issues was the inability to auto generate documentation, significant performance differences, and better support for unit/integration testing.
Rather than advocate specifically WCF, I'd recommend WCF Data Services or OData, with the stipulation that you'll need to secure it. If you go for pure WCF, you'll see that you'll end up creating a lot of code to handle retrieving the info from a database, and then sending that information right back out to your clients. It doesn't sound that bad, at first, but after about 30 entities in a database, you'll quickly grow tired of a pure WCF solution.
OData is great, it uses Entity Framework, and it quickly opens data manipulation for an existing database or one you are going to make. It will save you a ton of development time, if you can make your service secure. The format of the data response is flexible. There are plenty of client libraries ported for other programming languages as well.
The steps for securing a service are pretty simple. Always deploy to https. Any login or registration methods , need to be post methods, that return a token (Encrypted value), or a unique secret that can be encrypted and sent back for any subsequent requests. It's better to use the token, and have an expiration on the token.. because otherwise both your service and your app whether mobile or desktop, need to have a shared encryption / decryption method.
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