In .Net, I think about a web service as being a project type that you select from the menu, define your classes and methods then .Net does all this black magic under the hood to allow someone on the other side of the world to reference my web service and start coding using my classes and methods directly within their visual studio.
So having this preconceived notion, when looking at writing REST web services using MVC 3 (I know MVC 4 has a REST api baked in but am waiting for a full release) I'm wondering all the usual stuff like "is this a good idea", "will this stand up to heavy use" and "am I just writing toy web services that other developers will laugh at".
Now I think a lot of my anxiety is probably down to microsoft not having wrapped a big, overly complicated, bloated, shiny REST package around it yet. So I'm looking to have my anxiety relieved hopefully by people telling me yes MVC web services are perfectly good things to create.
Any help?
I've done it a few times, I am still using it in production and haven't got any complaints.
I actually think its a nice solution because it so simple to setup and maintain.
Not this incredibly xml-configuration-heavy wcf stuff..
You might want to also have a look at the WebAPI stuff that is in the process of being released (.net 4.5):
http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx
It's very much to do with exposing plain html services.
I would suggest you take a look at ServiceStack: http://www.servicestack.net/. It 's not only quite mature, but it can help you produce cleaner code.
It really does depend on what you plan on doing with your application. Yes, you could write an MVC website that doubles as a RESTful service. However, you are then tying your UI layer very closely to your logic layer, and that is what you really need to consider. I am working on an MVC site with a ServiceStack REST service (already mentioned by #Ioannis) . The reason that I did not make MVC my REST service is because I did not want any changes in my UI to potentially affect any third party application that might be using my logic service. So, as long as you carefully consider the ramifications of making your site also your RESTful service, then either decision could be ok. :)
As others have mentioned here, ServiceStack provides a solid, terse REST Web Services Framework allowing you to effortlessly develop typed, idiomatic C# API's end-to-end.
ServiceStack also includes a number of high-performance components that deeply integrates with ASP.NET MVC using the ServiceStack.Host.Mvc NuGet package.
To learn more about the benefits ServiceStack can add to your MVC project see:
http://www.servicestack.net/mvc-powerpack/
Related
Brief overview, I am working with Visual Studio 2017 and .Net Core 2.1. I am about to begin development on a website which will handle integrating 3 existing pieces of software which our company uses.
I have created WCF services already for use by some of the applications I have developed, but for this project, there are multiple APIs which I will be utilizing. It's quite possible that I may need to use these APIs in other projects down the road.
I apologize if this is an opinionated question, but here it goes, do you think it is good design to develop one central API which wraps all the calls to the integrated system APIs? My thoughts were that in this way, I only have to write the code once for making the desired API calls and I can then add to this API as I see fit moving forward, ie. another system API is needed.
Please feel free to give advice, I am still learning and appreciate constructive advice. I am using this to get started on building my API using .Net Core 2.1, https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-2.1
If the APIs are related then yes it does make sense to create a single assembly to call those for you and deal with the responses. You'd then consume that assembly in all your other apps.
However, if the APIs are completely different and require different set ups, then it may make more sense to create an assembly wrapper for each to keep the concerns separate.
You don't want to confuse the APIs. If anyone was to look at your code or assembly, they should be able to say that it relates to what it describes and not have to guess.
I have a specific case and I want to know the best practice way to handle it.
I make a specific .NET framework (web application). This web application acts like a platform or framework to many other web applications through the following methodology :
We create our dependent web applications (classes for the project business, rdlc reports) in a separate solutions then build them.
After that we add references to the resulted dll in the framework.
And create set of user controls (one for each dependent web application) and put them in a folder in the framework it self.
It works fine but any modification to a specific user control or any modification to any one of the dependent web applications. We have to add the references again and publish the whole framework !!
What I want to do is make those different web applications and the framework loosely coupled. So I could publish the framework one and only one and any modifications to the user controls or the different web applications just publish the updated part rather than the whole framework .
How to refactor my code so I can do this?
The most important thing is :
Never publish the whole framework if the change in any dependent application, just publish the updated part belongs to this application .
If loose coupling is what you are after, develop your "framework(web application)" to function as a WCF web service. Your client applications will pass requests to your web services and receive standard responses in the form of predefined objects.
If you take this route, I recommend that you implement an additional step: Do not use the objects passed to your client applications directly in your client code. Instead, create versions of these web service objects local to each client application and upon receiving your web service response objects, map them to their local counterparts. I tend to implement this with a facade project in my client solution. The facade handles all calls to my various web services, and does the mapping between client and service objects automatically with each call. It is very convenient.
The reason for this is that the day that you decide to modify the objects that your web service serves, you only have to change the mapping algorithms in your client applications... the internal code of each client solution remains unchanged. Do not underestimate how much work this can save you!
Developing WCF web services is quite a large subject. If you are interested, a book that I recommend is Programming WCF Services. It offers a pretty good introduction to WCF development for those who come from a .NET background.
I totally agree with levib, but I also have some tips:
As an alternative to WCF (with its crazy configuration needs), I would recommend ServiceStack. Like WCF it lets you receive requests and return responses in the form of predefined objects, but with NO code generation and minimal configuration. It supports all kinds of response formats, such as JSON, XML, JSV and CSV. This makes it much easier to consume from f.ex. JavaScript and even mobile apps. It even has binaries for MonoTouch and Mono for Android! It is also highly testable and blazing fast!
A great tool for the mapping part of your code is AutoMapper, it lets you set up all your mappings in a single place and map from one object type to another by calling a simple method.
Check them out! :)
Decades of experience says: avoid the framework and you won't have a problem to solve.
Frameworks evolve like cancer. The road to hell is paved with good intentions, and a good portion of those good intentions are embodied in a colossal tumour of a framework all in the name of potential re-use that never really happens.
Get some experience and knowledge when it comes to OO and design, and you'll find endless solutions to your technical problem, such as facades, and mementos, and what have you, but they are not solutions to your real problem.
Another thing, if you are using MS technology, don't bother with anything beyond what .NET offers. Stick with what the MS gods offer because as soon as you digress and become committed to some inhouse framework, your days are numbered.
I'm maintaining an application which currently is just a web service (built with WCF) and a database backend. The web service is built in layers with a linq-to-sql data access part with core functionality in an own assembly and on top of that the web service assembly which contains the WCF code. The core assembly also handles all business logic rules (very few actually).
The customer now wants a Web interface for the application instead of just accessing it through other applications which are consuming the web service. I'm quite lost on modern web application design, so I would like some advice on what architecture and frameworks to use for the web application. The web application will be using the same core assembly with business rules and the linq-to-sql data access layer as the web service.
Some concepts I've thought about are:
ASP.NET MVC (or MVC-2)
Webforms
AJAX controls - possibly leting the AJAX controls access the existing web service through JSON.
Are there any more concepts I should look into? Which one is the best for a fresh project?
The development tools are Visual Studio 2008 Team Edition for Developers targeting .NET 3.5. An upgrade to Visual Studio 2010 Premium (or maybe even Ultimate) is possible if it gives any benefits.
Definitely dig into ASP.NET MVC2.
All of our projects are now being developed using ASP.NET MVC2. It's not just highly scalable. It's highly testable as well. Which leads to way better maintainable apps in the long term.
WebForms vs. MVC2 points - (speaking out of experience):
Scalability:
In our company we had a lot of applications using WebForms which then were updated and changed by us as needed by our customers.
I think your customer will be requesting more changes on the application in near future. Making calls to other services, and maybe you'll have to rework parts of the final product to match their wishes.
And with the upcoming Cloud Computing and the Windows Azure platform you'll probably need to keep up with your code.
ASP.NET MVC absolutely supports the concept of being able to scale up your application any time you want.
I remember one of our customers walking up on me asking me for an extension for their app (they have a member management system) and the feature would contain something like a link to export the current view as a csv file so they could do office stuff with it (mostly serial letters).
It wasn't really a big problem setting that feature up. (took around 2 hours including writing tests) - let's go to tests:
Testability:
Using WebForms we didn't really have much interest writing tests because it was a pure pain to do so.
I remember writing some tests to have at least some proofs but let's drop that topic.. (:p)
We had tests for our custom classes but we couldn't really test all the EventHandlers within the WebForms.
Our CodeBase is way cleaner and saver to use thanks to this testable environment. I just check out some of the code, modify it, run all the tests and: Oh, it broke on strange behavior! - Let's fix that again. Earlier, I remember sitting with my co-worker debugging and trying to find those bugs for hours.
With ASP.NET MVC2 we are now lacking tests!
We ask all kinds of people (even the non-Web ones) to provide test-cases we could feed into our TestSuite.
And yeah, there are some AJAX-Controls too:
AJAXability:
You asked about AJAX Controls and in conjunction with ASP.NET MVC I highly recommend you to check out Telerik ASP.NET MVC UI Controls.
If that isn't something for you, we also make extensive use of jQuery and jQuery UI
With ASP.NET MVC and the HTML Views, those libraries aren't just a pleasure to use, they just look amazingly beautiful.
There is no random-html-tag-id-value autogeneration anymore!
But what I like most is: You can finally really re-use your code again.
There is so much more to those frameworks than just that, there is the T4 templating system. Auto-Scaffolding for your ViewModels / DomainModels with the Html.EditorFor() method and of course there is a great and easy way to use the IoC and DI paradigms.
Assuming that you have asked the question with mostly .NET Framework related tags, you'll probably stick with it.
Just to keep the post complete, there are also other frameworks that are just as good (or even better):
Ruby on Rails
Django
CakePHP
And many many more!
There's also DynamicData which may be appropriate if you need simple CRUD access to your data.
The Web Service Software Factory (WSSF) might come in handy in your situation.
This will allow you to define your contracts (XML entity returned (if XML you choose), etc.) while designing the server/client communication using WCF (or standard Web Service communication protocol).
WSSF favors either ASP.NET MVC or ASP.NET MVP. A simple example of the MVP architecture is shown here, plus this article.
As for me, I often come with a hybrid-like architecture using a bit of both MVC and MVP, as both have different strong points which combined together fill each other's improvement points.
I'd also recommend looking into Silverlight.
http://www.silverlight.net/learn/
Just my opinion to use MVC on Client sites and WebForms inside administration pages(site)
I'm currently working on a project that has a sizable amount of both client and web code. The client code is written in C# and the web piece is written in PHP. Maintaining consistency between the two worlds is becoming cumbersome, and I want to consolidate the web code to .Net.
The issue is that I hate web development in ASP.Net Web Forms. I want something as raw as PHP, just using C# instead. I've read a little about ASP.Net MVC, but it looks like it abstracts too much of the request logic for my liking.
Does anyone know of a lightweight way to allow C# + .Net to handle web requests? Should I be looking more closely at MVC?
Update: I went with ASP.Net MVC and I've been very pleased so far.
If you're looking to get away from ASP.NET Web Forms, the I recommend ASP.NET MVC with a custom view engine (like Spark, or NHaml). This will give you the consolidation your looking for and allow you to avoid most of the Web Forms that your not happy with.
AFAIK, to do .NET web development, you are going to have to interact with ASP.NET in some form or another, but the custom view engines in MVC could be exactly the abstraction your looking for.
It is now possible to use a software stack completely separate to IIS and ASP.Net using Kyak, Nancy and Gate.
http://bvanderveen.com/a/gate-0.1.0/
You might want to check out Kayak, which is, to my knowledge, the only standalone .NET web development framework that's not ASP.NET.
Caveat: Kayak's request handling implementation is not the best, so there may be performance or scaling issues. I can't say for sure -- I've only read it, not run it.
Edit: I've taken another look at the source code, and it looks like they've rewritten a significant portion of their server code, and in doing so fixed the major issues. Performance probably won't be a problem.
MVC.NET is open source, so you can make it do what you want. It is a framework that is overrideable, extensible, etc. I'd look closer at it. It works great for me and I've come from a background of CGI, Struts and Webwork. I love it.
In my opinion nothing is more lightweight than the combination of NancyFX (http://nancyfx.org/) with Dapper (https://github.com/SamSaffron/dapper-dot-net) for data access.
NancyFX can be hosted within ASP.NET, WCF, Azure, OWIN-compatible environments, Umbraco or you can write your own host.
Read also these articles:
http://theothersideofcode.com/lightweight-development-in-dot-net-nancy
http://theothersideofcode.com/lightweight-data-access-in-dot-net-massive
I also suggest you to TinyIoC (https://github.com/grumpydev/TinyIoC) for decouple your application layers.
Regards,
Giacomo
You should look into the IHttpHandler and IHttpModule interfaces. These are the foundations for ASP.NET WebForms. Brad Wilson has a good intro to the former.
In the bad days when WebForms was the way to do ASP.NET development I was writing my own simple MVC framework with these interfaces. The bit I struggled with at the time was the View engine but now there are a number of these.
You take a closer look at ASP.NET MVC since the source is available and decide for yourself. It may be that you want to change some of the conventions used rather than the whole framework.
The company has a PHP app that is in horrible condition. They want to start making plans to redesign it in .NET, however they need to run with the current design because of various reasons that I won't get into here.
They want to make some enhancements to the current design but do it in such a way that those enhancements can be in-part reused by their .NET version when it comes along. One idea to do this was to make the data and business logic portion of the app reside as a .NET webservice that would be consumed by the PHP end.
My question is will this cause problems in PHP? Can PHP consume .NET web services quickly and efficiently? Or is this just a bad design decision?
My question is will this cause
problems in PHP? Can PHP consume .NET
web services quickly and efficiently?
Or is this just a bad design decision?
I have two thoughts here. First to answer your question directly. I don't believe it's a bad design and if the .NET services are written language agnostic then there should be little issue.
The second thought is a "hope". I hope the choice to go with a .NET framework was not due to poorly written PHP. Changing languages because of poor implementation in my opinion is where the design fails. There will be more effort converting to a new language than there would be if the company choose to re-write the PHP and the end result would be a single unified language base with built-in legacy support. But then I'm a PHP fan.
For PHP to consume .NET webservices quickly you'll need to use PHP5 native SOAP Client API, enabling cache to store WSDL locally. If you use PHP4 you can use Nusoap, but it isn't as fast as native classes.
The whole point of having a webservice is interoperability between various development platforms. For instance twitter is a rails-based website and its services are consumed by multitude of various desktop and web applications written in .NET, java, python, etc, through its RESTful web-api. Facebook is PHP and C++ based as far as I know and how many webapps consume it's services through api. SO I don't think it's a bad idea. The question is how you implement this webservice. Meaning, do you want to use it once and then get rid of it or sue it for a long time. If the second option is true - make sure you design your webservice api with that in mind. Also PHP can easily consume XML-RPC and SOAP. I used both ( provided by a Perl based service) without any problem or big hits on performance.
I think using .NET to migrate from PHP is not the smartest choice - but that is somewhat subjective opinion. In my experience it almost always ended being an overkill, badly designed, more expensive to maintain and more buggy - because of the nature of the beast.
P.S.:
I'm not a PHP fan, but I don't believe in converting to .NET for the sake of converting. Also .NET infrastructure is more expensive to maintain and much more labor intensive.
The primary advantage of a webservice is its interoperability, or ability to be consumed by others independent of language. PHP should have something that allows it to consume webservices so that shou;dn't be too big of a deal. The disadvantage will be that it may be a little slower, but this is something you'd have to test out to see how much of an impact that has on your overall solution. Generally most solutions aren't inherently right or wrong, you have to test their usefulness to your particular circumstance.
PHP can consume .NET web services fine, as long as you stay away from WSHTTP based web services and use BASIC HTTP. You can secure BASIC HTTP web services with SSL for security.
WHen you are in Visual Studio 2008, and you have an ASP.NET (could be MVC or not, doesn't matter) project open, right click on the project and select "Add New Item." You will see see something under Web, called Web Service. This will create a .asmx file and you can find tutorials on how to create these basic web services.
Another alternative is to use Windows Communication Foundation, which has a lot of helpful classes, but it can be more complicated. The default configuration for a WCF service is WSHTTP, but it is possible to make a BASIC HTTP web service with the WCF too.
Not really much of a problem at all, just investigate your options.
Web Services can output data in a wide variety of formats. SOAP/XML are the default but there is no reason why you can't do YML, Xml serialized objects, or my current favorite JSON (which makes calling into it from a browser really easy).
Look also into WCF services, I believe they're supposed to supplant the Web Service format.
Finally, if you're looking for best practices check out Service Oriented Architecture. Its a large and varied field and this is exactly the sort of things they talk about.