One of the project I am working the project architect is saying that we should make each layer as a separate maven project for e.g. For entity beans there is one maven project for dao interfaces separate project dao impl there is another project service interface there is one project service impl there is another project and controller is another project. In controller we are adding entity, dao and service project as dependency. Is it the right structure? What are the drawbacks and benefits of this structure? What should be the right way to micro services project structure?
We have 9 microservices so there are almost 40 projects. It feels clumsy.
you need to make separate projects for things which are consumed directly by other microservices like Beans. For eg: and things which are part of microservice impl.
Why we need to make separate:
Service A has 5 Beans which are exposed on using API IServiceAAPI
Now Service B use Service A by using API IServiceAAPI(assuming your framework automatically create a IServiceAAPI Object which calls the actual service) and return one of the beans. So either you rewrite those beans of use the original API from Service A, as it helps when the API changes your code automatically get the updates.
In general it makes sense that you have one project named ServiceAAPI which contains API, Beans and other project named ServiceAImpl
Related
Good day all.
I have an asp.net core solution (NopCommerce 4.4) where I'm registering multiple classes that inherit from Microsoft.Extensions.Hosting.BackgroundService. These are using Dependency Injection to get access to several other classes at runtime.
Some of these DI classes need to know which specific class (derived from BackgroundService) they were instantiated in so they can return data specific to the background service that's "hosting" them. For example, each Background Service has it's own ECommerce Store it's responsible for processing data in.
How can I determine what Hosted Service is the "context" for the DI classes that it is requiring?
I'm creating a new application in Zend Framework 3 and i have a question about a design pattern
Without entering in much details this application will have several Services, as in, will be connecting to external APIs and even in multiple databases, the workflow is also very complex, a single will action can have multiple flows depending on several external information (wich user logged in, configs, etc).
I know about dependency injections and Zend Framework 3 Service Manager, however i am worried about instanciating sereval services when the flow will actually use only a few of them in certain cases, also we will have services depending on other services aswell, for this, i was thinking about using singletons.
Is singleton really a solution here? I was looking a way to user singletons in Zend Framework 3 and haven't figured out a easy way since i can't find a way to user the Service Manager inside a service, as I can't retrive the instance of the Service Manager outside of the Factory system.
What is an easy way to implement singletons in Zend Framework 3?
Why use singletons?
You don't need to worry about too many services in your service manager since they are started only when you get them from the service manager.
Also don't use the service manager inside another class except a factory. In ZF3 it's removed from the controllers for a reason. One of them is testability. If all services are inject with a factory, you can easily write tests. Also if you read your code next year, you can easily see what dependencies are needed inside a class.
If you find there are too many services being injected inside a class which are not always needed you can:
Use the ProxyManager. This lazy loads a service but doesn't start it until a method is called.
Split the service: Move some parts from a service into a new service. e.g. You don't need to place everything in an UserService. You can also have an UserRegisterService, UserEmailService, UserAuthService and UserNotificationsService.
In stead of ZF3, you can also think about zend-expressive. Without getting into too much detail, it is a lightweight middleware framework. You can use middleware to detect what is needed for a request and route to the required action to process the request. Something like this can probably also done in ZF3 but maybe someone else can explain how to do it there.
I have a WPF application that uses a WCF services to perform operations on entities using EF4.
My project structure is as follows:
Project: EntityObjects
this is where the edmx file lives
Project: WCFService
References EntityObjects
Has data contracts to perform actions on entities
Has three different svc files, called Partner.svc, Section.svc, Scheme.svc
Project: DataLayer
has service references to Partner.svc, section.svc, scheme.svc
The problem is that the DataLayer project then has ambiguous references to objects as each svc file returns its own references of the entity objects.
How do I get around this?
It will not work this way. If you want to have same data contract types among all three service references you must use data contract sharing. That means that your data contracts must be provided to client project in separate assembly prior to adding service references. Most often this means that you will share data contract assembly between server and client. In your case it means sharing EntityObjects with whole EF stuff - that is bad.
There are multiple solutions:
Placing entities and EDMX stuff into separate projects and share only project with entities
Use custom Data transfer objects instead of entities as data contracts and share assembly with these DTO
Don't share assembly and instead create "copy" of data contracts manually for client
Don't expose same entities through different services
Use only single service if it makes sense in your architecture
Last two choices are more about architecture of your application.
You could :
Build a wrapper class that wrapped access to all 3 services. Then reference the objects concerned in the DataLayer project directly rather than through the service and convert as required in the wrapper class.
I have an class library called ServiceLayer which acts as a repository for a ASP.NET MVC application This service layer has a references to a WCF Service called ProfileService which contains Profile methods to perform CRUD operations on a database etc.
I now need to allow mobile devices to communicate with my application so I have created another WCF Service called ProfileService. This service has a reference to the ServiceLayer class library and makes calls to it to undertake Profile operations.
Now this is quite confusing as I now have 2 ProfileServices. The first communicating with my database etc and exposing itself to my service layer. The second communicating with my service layer and exposing itself to mobile devices.
What is the best way to name your services in a SOA environment to avoid confusion of which type is which? especially when mapping between types.
I may also want to create another service which acts as an API to users of the system. What would I name this service ProfileAPI?? I know each ProfileService is in its own namespace but this doesnt help with readability when creating AutoMapperSettings or performing manual mapping.
So if anybody out there knows of a good way to name services in this environment it would be much appreciated.
You are looking for a Service Facade
You would end up with a Facade, which is just a specialized interface into your real service. You would define the different services as needed (mobile, users, database)
Is it an acceptable programming practice to add a Service Reference to a Project where the Service being referenced is defined within the same VS Project? (Service and Service Reference are in the same Project)
example:
MyWebAppProj
-Services
--MyService
-Service References
--MyServiceServiceReference.MyServiceClient
-Default.aspx.cs uses MyServiceServiceReference.MyServiceClient
The rational behind this is that a Silverlight App may be added to the Project. If it is, we would have to expose all the Business Logic methods through a service layer, so why not just do that first and use them everywhere to stay standardized between web pages and Silverlight pages.
I can't see why you would want to do that at all.
If you're already inside the same project as the service, at the very least you've already got access to all the service/data contracts, so really, calling the service is already very, very easy. You can either use a ChannelFactory directly, or write your own custom ClientBase<T>-derived client proxy class (which is trivial), there's no reason why you'd want to add service reference in this case.
Furthermore, if you added a service reference, you'd then be stuck with a bunch of duplicate definitions in the same project, which makes little sense (yes, you can isolate the generated code into a separate namespace, but still).