I have three core applications that have their own business functions (networks, active directory and helpdesk). Each are running ASP.NET v2 or v3 and have their own respective databases. However, the application functions have merged a bit so models were recreated in each application and app logic along with it. So now I have some difficult to maintain code. So here is my question:
Is porting my models and repositories over to WCF a reasonable choice for this type of architecture?
Is using a service stack such as serialized json calls a better choice? I'd imagine this would be faster than setting up a central wcf app.
I'm not too familiar with communication between asp.net mvc web apps so please point me in the right direction.
I would recommend developing a service layer per the design pattern described by Fowler. This service layer encapsulates the various domain models and repositories and handles interactions between different domains/models. This will be an assembly and not a WCF or any other type of web service. If you require a WCF web service then it will be a very thin layer which basically has a contract that mimics the service layer and only purpose is to provide a web service interface or API.
There are a couple of ways an MVC application can interact with your service layer. If you are creating view models in your Controllers then it can access the service layer assembly directly. There is added overhead to calling it through a web service that is most likely not necessary in this case. Using this approach the service layer is pretty much your Model in the MVC trio.
The other way to access the service layer is from the Views/client using AJAX for rich clients. In this case you would use MVC to put a REST API on top of your service layer so that you can make AJAX POST's, using something like JQuery, directly to the web service to update and retrieve data for the web page.
Note with this architecture you can use a combination of both approaches. You may access the service layer directly from the Controller to render some initial pages and then use the web service REST interface for AJAX calls during user interaction.
Related
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
What is the difference between making calls to mvc controller methods and WCF WEB API Rest Service Calls?
I can create an mvc controller post method that will allow me to execute any code i need.
I can also create a WCF Web API REST Service with MVC.
What is the difference between these two approaches to accessing data ?
More specifically what are the advantages of utilizing WCF in this scenario ?
WCF Web API handles XML and JSON out of the box whereas you'll have to create your XML and JSON "by hand" (read: using the Serializers) when using MVC - this is only one of the benefits of WCF Web API over MVC.
Another one is the level of separation WCF Web API offers e.g. implementing your service logic vs. content negotiation.
Yet you can easily use IoC containers and unit test your APIs being created using WCF Web API.
WCF Web API mainly has been created to build ReSTful API's whereas MVC just allows it to create them too - thus with WCF Web API you'll feel more comfortable creating ReST APIs.
If you're planning to start a project from scratch as an Web (ReST) Api, you should start with WCF Web API.
If you're planning to start with a Website that also offers ReSTful Services, you should suggest MVC.
You should also regard this tweet from Glenn Block.
You could accomplish a typical REST API with either one.
Usually the issue boils down to (1) what specific features you need and (2) what technology you are more familiar with.
There are some features of WCF that are really neat and not available in MVC (like binary serializations, the ability to host without IIS, et cetera) but those are not typically requirements in a REST API.
Overall I would say:
If you have an WCF implementation already in place and want to expose it as a REST API go for it with WCF.
If you already have an MVC site and want to expose it as a REST API stick with MVC.
I wanted to get some peoples opinions on adding a web serivce layer. At my work, we want to start using web services to handle some of our operations.
Our current project structure that we follow for our ASP.NET MVC apps:
MVC App (View/Controller/ViewModel/Service Layer) --> BAL (Business Access Layer) --> DAL (Data Access Layer)
The MVC app, BAL, and DAL are separate assemblies.
There is a Domain (model) assembly as well that is shared among the MVC/BAL/DAL layers.
The plan is to create a web service that will handle all security functions. This web service will be used by multiple web applications. When we make changes to the Security Web service we only want to modify code in one place and not every web app. So I'd prefer if the MVC project has nothing in it that is tied to a web service.
So I was thinking of adding a Web Service Layer between the BAL and DAL layers.
So something like this:
MVC project (View/Controller/View Model/Service Layer)
calls
BAL Layer (Handles caching / DB Transactions)
calls
Web Service Layer
calls
DAL Layer
What are your opinions?
A couple thoughts.
You are putting your web service layer between you BAL and DAL. This means everything will need to go through your web service, including functions which aren't related to security. I think this is adding an additional layer of complexity. If multiple websites are using the web service, create it as a stand along application/service. Then you can call the service from the different layers of your application depending on what layer needs the service. Generally you would create a Webservice wrapper with a clean interface so you can easily call the Web Service from your any layer in your application.
For the sake of discussion, lets say your web service handled validation of login and password of a user. You can connect to your webservice wrapper directly in your MVC project to see if the user data is valid, then you can log them in if it is. Later, if the user performs a function, and the business layer needs to check if the user has permissions, that layer can use the api wrapper which calls the api to see if user has permissions, and so on.
MVC APP
/ \
BAL --> Web Service Wrapper
/ \
DAL WCF WEB SERVICE
As someone who supports an application that is ridiculously layered as so.
GUI
BAL
DAL to WebService
Webservice
WebBAL
WebDAL
I would suggest putting your GUI as close to your webservice as possible.
I want to send an email confirmation from my service layer (class library). This can be triggered from an asp.net mvc controller or a wcf service.
How do I build the Url from the service layer?
The service layer shouldn't have knowledge of how urls are constructed in your web application, especially because those rules can easily change. Also this makes your service layer tightly coupled to the web layer and less reusable. What if tomorrow you wanted to reuse this service layer in a desktop application?
IMHO that's an information that should be passed from the controller to the service layer.
My ASP.NET MVC 2 controllers are currently instantiating service objects in their constructors by passing repository instances that are instantiated by Castle Windsor. I have unit tests that call the controller actions after passing Moq instances of the repositories to the controller's constructor.
I want to allow a third-party UI to access these service objects through WCF.
It occurred to me that converting my existing Service layer into Web services or even adding a new Web service layer between the UI and the existing Service layer will break my unit tests unless I find a way to bridge that gap.
I was trying to work out a solution where my UI was coded against an interface of the service layer (it already is) and I could use DI to pass the Web service implementation at run-time and pass the existing implementation during unit testing. The Web service implentation would simply call the existing implementation.
Questions:
Is such an approach advisable / possible?
Are there any examples of this in a tutorial or open source project?
EDIT:
I believe I have a workable solution now thanks to the suggestions below. I created a WCF Service Application that uses the existing service interfaces from my domain model. The WCF implementation is a class where the constructor takes repository instances from Ninject's WCF extension and creates an instance of the service from the domain model. Each method/function in WCF simply calls the same method/function from the existing service layer.
There were some caveats. For example, I can no longer pass a reference to my ASP.NET MVC ModelState when I create the service in the controller (actually, I use Ninject to create an instance of the WCF service and supply that to the controller's constructor). The reason is that WCF is a messaging platform - changes must be explicitly communicated back with each call (i.e. my validation errors are now communicated back as reference parameters on individual functions/methods).
I also had to add some serialization/servicemodel references to my formerly POCO Core project.
Also, I switched from Castle to Ninject because Castle's WCF solution has a maturity level of low and I wasn't comfortable using that at this time.
Can you explain in more detail why your tests would break?
I do this type of development all the time. Services as classes => services as WCF services.
Your tests shouldn't break. A WCF Service is almost 100% contract, the underlying business code and logic shouldn't have to change.
Check out the Web Services Software Factory created by the Patterns & Practices team. It is a good way to structure your services into contract projects (data, message, service) and "business code". Once you get a better understanding of how to structure your code, you can refactor their style to something that fits you a little better. Their example tends to separate everything into lots of VS projects, which can be a little overkill for most shops. Example, I don't see many shops sharing data contracts across projects. Yes, in a perfect world, you should probably share a lot os types (like address) across projects, but I don't see it done very often. So, I tend put all my contract stuff in one VS project.
If your services are already defined as interfaces then you've got a head start.
Pass the services into the controllers as constructor dependencies, rather than the repositories. Let your DI container A) provide the repositories to the services, and B) provide the services to the controllers.
If you want to stand up your service layer as wcf services to be accessed by other applications, you'll want to use the wcf service factory to pull the concrete service implementations out of your DI container. Here's an example with windsor, it should be easy to adapt to whatever container you use.
At this point you can modify your website to either A) continue to invoke the services directly, or B) have them call back to the web services using service clients. There are pros and cons to both methods.