My company provides a large scale SOAP application with .Net WCF. Inside this existing WCF application we now need to host an Asp.net MVC 4 (or 5) website. This means we need some kind of routing, that URIs of a specific kind are completely redirected to the Asp-Subcomponent and processed as if it was a separate application.
Searching for this issue I only find solutions where you do it the other way round - for sure the routing inside Asp MVC towards a WCF subcomponent would be quite easy and straight-forward.
However, this is not possible in our case. The WCF contains a lot of security hooks we can not (and absolutely do not want to) transfer into the Asp component. On the other hand, dividing it into two separate applications and let IIS do the routing is also no possible solution, since our application as a vast bunch of dependencies with other software packages of our company which we do not want to maintain twice in separate apps.
The existing WCF component is hosted as a separate web application inside a IIS 7.5 with a .NET 4.0 application pool.
Is there any reasonable way of sub-routing from WCF to Asp.net MVC?
This approach sounds like it is going to cause you and your company more issues than it is worth.
I see that you've mentioned that splitting it into two separate components is impossible, however I would consider it for a few reasons.
Authentication and Authorization in WCF and MVC differ considerably, I would refactor these this code into a library that wasn't dependent on each technology and then write a WCF and MVC abstraction for each application. That was you get reuse but also have two components that understand the underlying technology
Routing WCF doesn't understand routes, it only has a sinlge entry point. Decision making of which method to be called it embedded in the payload of the message.
MVC on the other hand routes based on the url.
Deploying Updates to the MVC site will require WCF Service updates and vice ce versa
These are just some off the top of my head. It just seems overly complicated and hacky to do it this way.
I'd consider two applications hosted separately in IIS with common logic extracted into common class libraries that allow for reuse.
I suggest you give WCF Services and ASP.NET a thorough read.
You are going to find it extremely difficult (or at least pioneering) to get WCF to sit between IIS and ASP.NET. They are designed to work side by side, or independently.
Given it's pretty straightforward to have WCF and ASP.NET/MVC use the same underlying authentication system (e.g. Forms Auth), your main objection to architecting it right seems to be the "vast bunch of dependencies with other software packages of our company which we do not want to maintain twice in separate apps".
Again solving that seems to be a pretty straightforward bit of refactoring. Your task would be just to extract out all the WCF specific code from the business logic, then put the business logic into a separate class library to be shared between WCF and MVC apps. To me there is no other sensible approach to solving your problem than this. Any other approach is probably going to leave you even more of a mess than the (monolithic sounding) WCF app you have currently.
Related
We released a WPF client server application this year . It has a client (with a few dlls ) and server on the server machine (with multiple dlls with most of our logic). The server side uses Entity Framework and the service between them is TCP /IP Windows communication foundation (WCF).
The client uses MS Prism with Mef for MVVM. The UI has a number of Datagrids for storing , saving data.
For WPF we have :
XAMl -> View Model -> Service Interface -> Server Side code -> DB
For ASP.NET , we expect to use the layers from Service Interface onwards as it is.
So , basically we need :
Website-> Logic for data handling on client Service Interface -> Server Side code -> DB
Unit testability is not a very major concern as our unit test coverage looks good on the server side (85 % covered).
I read up on ASP.NET MVC and found some tutorials that spoke about building whole applications on the MVC framework .
Our case we have more than half of the application built and only need the client side web UI with same data .
My question is : Should we go for ASP.NET Web forms or MVC ?
Web forms have native controls like GridView which can be used. MVC doesnt provide much native controls support . MVC covers the whole web app full stack. We only need the client UI website.
People around have recommended MVC since it is new and looks like the way forward but I am wondering if it would be overkill considering our requirements ( only need client). Would MVC force us to rework our whole layers even on the server side ? Will aSP.NET web forms not do this ? We want to be able to use WCF instead of doing any other http framework like webapi.
I know this question has been done to death with but these are some speicific requirements here. I also read up on porting WPF apps to Web but tat probably wont work out as we may have some fucntionalties different in the Web vs WPF.
Having worked with both MVC and Web Forms I would highly recommend going with MVC. In my opinion Web Forms is an antiquated pain-in-the ass that doesn't lend itself well to scaling or unit testing(which I know you said is not a huge concern).
Yes, Webforms has native controls like gridviews but you aren't missing out on much. These are good for very simple things but as soon as you add some complexity to your tabular data you're going to be pulling your hair out. What I'm trying to say is you can accomplish the same thing these built-in controls provide but with greater flexibility using simple tables or just plain old divs(and some css, of course).
I should also note that both MVC and web forms work just fine w/ WCF. You don't have to use WebApi if you're using MVC.
Lastly, I don't think there's an easy way of only providing "the client" piece of what your trying to accomplish with Microsoft technologies. If I understand your question correctly, you have a desktop application and now you want to provide a web-based equivalent UI. You're going to have to create a site using webforms or MVC to achieve that. However, you will be able to reuse your web services so you won't have to rewrite too much business logic.
You are making a small confusion. Since you have alredy a WCF(SOAP) backend service you will write only the UIClient, regardes of technology. You can do it even in Java.
Since you rewrite the desktop client, as a new web client you have to do it from scratch, and so should use ASP.MVC. You can find a lot of forums which can tell you why.
Web API is used, only if you want to create REST services in MVC. But you can build them also in WCF if you really need them.
The only good reason for ASP.NET, will the fact if you have developers which already know it, and you can save some money.
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 just got a project to be build up from scratch. Its front end will ASP.Net and Backend is SQL 2008. The requirement is, the architecture of the app should be such so that we can have access to app from any computers(desktop, laptop, netbooks) as handheld devices as well like smartphones, PDA's, Tablets. Also it should be plugable in nature like FB and orkut. That is in future if the client needs to attach games or third party applications, then it should be plugged in without rewriting the entire thing again. Also client needs the entire web ajaxified either using the toolkits or JQuery.
I have prior experience of ASP.Net webforms applications with tiered arcitecture. So this time keeping his all needs, i am thinking of a web app with WCF Service. But i have no idea or experience about the pluggable architecture with SOA and MVC (all three). It seems if I implement all the stuffs, it will going to be a mamoth of codes. For pluggable arch I googled and found MEF on codeplex. So finally I came up with the following things :
ASP.Net MVC
MEF
JQuery
WCF
RESTful with AJAX
XML
Guys, i really need your help, I am unable to think how to place all these stuffs together. Or is there any other best alternative you can suggest for.
Also, there is one more requirement by the client is that he want the loose coupled code, that's reason i chosen MVC, the aspx page can only have the controls and required HTML, validation and other codes should be done in the Business Layer of the app.
it will be great help.
You should take a look at Orchard: it's an ASP.Net MVC CMS system that is very pluguable. You can add a lot of functionnalities through modules, and there are a lot of modules already implemented and accessible.
Even if you do not end up using Orchard itself, taking a good look at its architecture should be a very good starting point for your app, as Orchard responds to a lot of the same requirements you have, and as it is an open source project, you can get as much inspiration from it as you want.
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)
More of a design/conceptual question.
At work the decision was made to have our data access layer be called through webservices. So our website would call the webservices for any/all data to and from the database. Both the website & the webservices will be on the same machine(so no trip across the wire), but the database is on a separate machine(so that would require a trip across the wire regardless). This is all in-house, the website, webservice, and database are all within the same company(AFAIK, the webservices won't be reused by another other party).
To the best of my knowledge: the website will open a port to the webservices, and the webservices will in turn open another port and go across the wire to the database server to get/submit the data. The trip across the wire can't be avoided, but I'm concerned about the webservices standing in the middle.
I do agree there needs to be distinct layers between the functionality(such as business layer, data access layer, etc...), but this seems overly complex to me. I'm also sensing there will be some performance problems down the line.
Seems to me it would be better to have the (DAL)assemblies referenced directly within the solution, thus negating the first port to port connection.
Any thoughts(or links) both for and against this idea would be appreciated
P.S. We're a .NET shop(migrating from vb to C# 3.5)
Edit/Update
Marked Dathan as answer, I'm still not completely sold(I'm still kind of on the fence, though leaning it may not be as bad as I feared), he provided a well thought out answer. I appreciated all the feedback.
Both designs (app to web service to db; app to db via DAL) are pretty standard. Web services are often used when interfacing with clients to standardize the semantics of data access. The web service is usually able to more accurately represent the semantics of your data model than the underlying persistence store, and thus helps the maintainability of the system by abstracting and encapsulating IO-specific concerns. Web services also serve the additional purpose of providing a public interface (though "public" may still mean internal to your company) to your data via a protocol that's commonly accessible across firewalls. When using a DAL to connect directly to the DB, it's possible to encapsulate the data IO concerns in a similar way, but ultimately your client has to have direct access to the database. By restricting IO to well-defined semantics (usually CRUD+Query), you add an additional layer of security. This isn't such a big deal for you, since you're running a web app, though - all DB access is already done from trusted code. The web service does provide an increase in robustness against SQL injection, though.
All web service justifications aside, the real questions are:
How much will it be used? The website/web service/database format does impose slightly higher overhead on the web server - if the website gets hammered, you want to consider long and hard before putting another service on the same machine. Otherwise, the added small inefficiency is probably not a big deal. On the other hand, if the site is getting hammered, you probably want to scale horizontally anyway, and you should be able to scale the web service at the same time.
How much to you gain? One of the big reasons for having a web service is to provide data accessibility to client code - particularly when multiple possible application versions need to be supported. Since your web app is the only client to use the web service, this isn't a concern - it's probably actually less effort to version the app by itself.
Are you looking to expand? You say it probably won't ever be used by any client other than the single web app, but these things have a way of gaining in size. If there's any chance your web app might grow in scope or popularity, consider the web service. By designing around a web service, you're already targeting a modular, multi-host solution, so your app will probably scale with fewer growing pains.
In case you couldn't guess, I'm a web service fan. But the above are also my honest (if somewhat biased) opinions on the subject. If you do go the web service route, be sure to make it simple - keep application logic in the app and service logic in the service, and try to draw a bright line between them when extending the two. And do design your service for efficiency and configure the hosting to keep it running as smoothly as possible.
This is a questionable design, but your shop isn't the only one using it.
Since you're using .NET 3.5 and running on the same machine, you should use WCF with the netNamedPipesBinding, which uses binary data transfer over named pipes, only on the same machine. That should mitigate the performance issue somewhat.
I like the idea because it gives you flexibility. We use a very similar approach because we can have more than 1 type of database storing our data (MSSQL or Oracle) depending on our customer install choices.
It also gives customers the ability to hook into our database if they choose not to use our front end web site. As a result we get an open API for little to no extra effort.
If speed is your most critical issue than you have to lessen your layers. However in most cases the time it takes for your web Service to process the request from the database does not add allot of time. (This is assuming you do your Web Service Layer Correctly, you can easily make it slow if you don't watch it.)