We've created some domain services. On top of our services, we've added a Web Api layer on top to allow RESTFUL interactions with our services. We are using StructureMap for IOC. To get this to work I had to reference the domain and repository projects to our Web Api project. I want to avoid this.
With these references, it could allow developers to start referencing domain objects or repositories in our service layer. Through code reviews we can prevent that but I'd prefer to remove the references completely.
Our container is registered in this manner:
IContainer container = IoC.Initialize();
GlobalConfiguration.Configuration.DependencyResolver = new StructureMapDependencyResolver(container);
[Service Layer] --> [Domain Services] -- >[Domain Models] and [Repositories]
How do I register these dependencies in our Domain Services but not the Web Api Service Layer? Or have an IoC container for the Web Api Layer and then one for the Domain Services? Domain Services is nothing more than a Façade/Orchestration. It can be consumed by a Web Api Service Layer, WCF Service, or directly from applications like WPF or WinForms.
Thoughts?
Related
I'm splitting up a monolith web service into several microservices using spring boot. To reduce duplicated code I extracted shared parts in a maven module that is used in the different microservices.
The monolith application had a healthcheck page that showed various information about the state of the service and some debbuging infos. It is implemented with Spring MVC and jsp.
I'd like to use this view in each of the microservices. Whats the best way to do this without duplicating the view/controller?
I was thinking of adding a web module to the shared maven project that contains the controller, view, spring mvc settings,...
But I'm not sure if it is good to have two web modules in one microservice.
Have you considered using spring boot actuator to retrieve health (and more) application information?
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready
You could then have another microservice that retrieves that information from each of your services, or just simply check it on then hitting the different endpoints (/health, /env, etc.).
UPDATE:
If you have you custom health logic you can even implement your own actuator endpoint for it. Furthermore, you can create your own library to reuse it in all your microservices:
http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready-customizing-endpoints-programmatically
46.4 Adding custom endpoints
If you add a #Bean of type Endpoint then it will automatically be exposed over JMX and HTTP (if there is an
server available). An HTTP endpoints can be customized further by
creating a bean of type MvcEndpoint. Your MvcEndpoint is not a
#Controller but it can use #RequestMapping (and #Managed*) to expose
resources.
[Tip]
If you are doing this as a library feature consider adding a
configuration class annotated with #ManagementContextConfiguration to
/META-INF/spring.factories under the key
org.springframework.boot.actuate.autoconfigure.ManagementContextConfiguration.
If you do that then the endpoint will move to a child context with all
the other MVC endpoints if your users ask for a separate management
port or address. A configuration declared this way can be a
WebConfigurerAdapter if it wants to add static resources (for
instance) to the management endpoints.
Currently VS 2015 Update 2 provides an easy way to create owin based stateless web api service using create new service template for service fabric application. Is there a reason why only stateless web api service template is provided and not stateful web api service? If I wanted to, can I modify the stateless web api service to derive from stateful web service? Is it that simple? Or are there any gotchas with this approach?
Web Api is intended to be facade/public entry point to the service fabric app. Being stateless saves the clients from dealing with resolving partitions/addresses and other hassle.
If you want to - you can modify web api service and make it stateful. Maybe it would be even easier to create stateful service from the template, install missing packages (that web api template has), copy OwinCommunicationListener and Startup, wire them into CreateServiceReplicaListeners override, and add valid service endpoint to ServiceManifest.xml. OwinCommunicationListener will provide unique address for each replica.
Yup, you certainly can modify it to be stateful. Web API is great for internal service-to-service communication as well as a public-facing API.
There is a caveat that we are currently working through: The web host for stateless uses Kestrel, which presents some difficulties for stateful services where multiple replicas share the same process, because Kestrel doesn't have the same port-sharing capabilities that http.sys-based hosts do. We're working on a solution that makes it easier to use Kestrel for stateful, but in the meantime you can always use the WebListener host, which is the http.sys-based host.
If you're interested, I'm working on a project that will have an ASP.NET Core 1 stateful service (among other cool things) that you can track here: https://github.com/vturecek/service-fabric-xray.
As I understand, the main point of Laravel's service providers and service container is to allow for DI. However Laravel also has "automatic resolution" whereby the framework appears to automatically inject any dependencies a class needs.. therefore when would you need to use a service provider and the service container?
I have an ASP.NET Web API 2.0 OData service project which I am trying to relay via a service reference + WCF Data Service (5.6) through an ASP.NET MVC project—the reason I am doing this is so users browsers’ can access the service without worrying about CORS for IE8 and IE9— so they will have the same host.
After some tinkering, this setup mostly works however there are some problems, my setup:
Service Project
1) ASP.NET Web API 2.0 OData endpoint
2) WCF Data Services 5.6 OData endpoint + Entity Framework 6.0.2 (EntityFrameworkDataService<DBContext>) using WCF Data Services Entity Framework Provider (1.0.0-alpha-2)
When I directly access both of these services they perform flawlessly with whatever I throw at them—both through a service reference, LINQPad, and raw URLs. Then I setup the ASP.NET MVC project:
ASP.NET MVC Project (relaying service references above): WCF Data Services 5.6, (DataService<ServiceReference-1-or-2>)
The problems come when I try to perform the same queries on the WCF Service acting as a relay:
Relaying (1) with $inlinecount=allpages gives me: “An error occurred while processing this request.”
Relaying (1) and (2) with $select=... both give me: “Not Implemented”.
When I relay a dummy POCO context through the reflection provider all of the operations work flawlessly on the relay WCF Data Service, which leads me to suspect that the problem is in the combination of WCF Data Services and the Service Reference, as they both work without problems independently… Perhaps the WCF Data Service is examining the LINQ Provider for the service reference and arbitrarily deciding that it does not support the operations?
I could live without $select but not having $inlinecount is a deal-breaker. There are a couple of alternate solutions I could take but I would really like to make this approach work: any ideas?
This was very similar to: WCF Data Service - Proxy mid-tier service
In a nutshell: you can have a relay by either
1) Making the service believe it is at a different URL than it is (so it is effectively broken for all access except through the proxy).
or
2) By writing another service which manually does the relaying to the service reference...
I chose none of the above and restructured my service as Web API Owin middleware. I lost the ability to have a separate service deployment but can easily swap in another piece of middlware and it makes CORS issues non-existent.
So we've decided to rebuild an application in our business since it's been sitting in Sharepoint for no apparent reason other than to make use of its document indexing feature.
We've decided to create our new app in ASP.NET MVC3 using C#. We're trying to decide on the overall architecture.
I was thinking something like the following:
Core - domain objects (poco's)
Data - Entity Framework (Code First) or nHibernate exposed as Repositories
Service - This layer would encapsulate any business logic and act as a facade. This could be broken down into further modules.
UI (MVC) - Controllers and Views.
This would all be tied together using a DI container such as Autofac.
We also want to be able to write unit tests so we need to be able to mock our service layer and data repositories for testing our controllers etc.
So - does the above sound like a good overall architectural pattern for a pretty standard business application?
The idea being that data, service, ui can reference Core but the UI would only really talk to the service level components and not know about the implementation details of data etc.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming?
OR
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
Any thoughts would be really helpful as I don't know what best route would be.
Should we use a WCF service as our service layer facade in nTier application
Depends on if any other application than the MVC application is going to talk to the service.
MVC3 is the only app: You aint gonno need it
Other apps too: Sure. Do it.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming
Don't use the concrete service classes. Use the service interfaces. Problem solved.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API
I hope that you mean the same WCF service.
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
ehh. What kind of method is Service1.CreateObject(object obj)? That looks just wrong.
Using WCF Service is the right approach. (As you need to host this as web-api and web-api is over http).
In your mvc application you can consume the service by endpoint url.
Time factor depends on the connectivity between your servers(WebServer for MVC app and the Server to host WCFservices).ideally it should not be a bottle neck.
Still you can do unit testing of MVC code (as service layer call can be mocked.(using Moq/NMock?RhinoMock...))