I have a .net Web API 2 application that I need to use to call an web service (asmx) just to see if the web service is up and running correctly. I am a believer in architecture, so with that in mind I am not sure where to put the call to the web service. I found a post that suggested that I put this in the repository layer. Is this the correct location for that?
I would say its more of a personal preference + project specific; IMO you can place that web service in repository if it acts as a data-store or you could place it in business layer of the service does more of a business related stuffs.
But one thing I would do for sure is to create a wrapper/abstraction over this service before using it in any layer so that:
I can inject this dependency in the layers its being used
Unit testable code - DI and mockable
No changes in the layers where this is being consumed in case there is any change in service- for eg, asmx1 to asmx2 or change in asmx service to wcf or REST etc.
Not sure whether you will be able to find a specific answer to this, this is kinda arguable subject as opinions might differ according to personal preference
Related
I am planning to create a service oriented application. For creating service I will be using WebApi and for web application MVC.
I have thought of two approach for the same kindly let me know which one better.
Create one business logic shared across MVC and WebApi and dont consume WebApi in MVC application. Just business logic will be shared.
Consume API in MVC application from WebApi project using HttpClient.
The question was a bit unclear but now, after comments it makes more sense.
I would go with option 1.
The first reason is that you can avoid a lot of traffic to the API if you can simply use the layer and don't bother with any APi calls at all.
The second reason, it will be a little quicker since it doesn't need to wait for the API responses.
Less pressure on the API means the mobile app has more resources to play with.
You can basically build your own Nuget packages, use them in both your Web and Api layers and you don't have to repeat the code.
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.
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.
I'd like to be able to get the url that the app is hosted on. There will be various ways that clients will access the service layer, through an asp.net mvc app, wcf (hosted on the mvc app).
My service layer is in a dll. Is there any way that I can get the url pointing to a specific action when a remote client uses either entry points to the system?
It is possible - but not a good thing to do. You are binding the business layer to an implementation detail which is higher layers and business layer should have no knowledge of.
You can use various OperationContext.Current properties (depending on your binding) to get to the address.
For example, OperationContext.Current.IncomingMessageHeaders can be used for HTTP or OperationContext.Current.Host.BaseAddresses if there are base addresses. You just need to evaluate which one provides the address you are looking for depending on your configuration.
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.