I'm currently working laravel5 for CRM application with the help of Repository method under Provider Directory. But i'm totally look blind to understand Service Directory, and purpose of this directory.
And can anyone give me example to utilize these directories by differentiate difference.
Services
Services are re-usable classes that do not belong in a controller. For example, a service which is required by more than one controller such as class for building site navigation. It is a good place to put "global" classes (global to your app), which can be injected into a controller for use across your application.
Providers
Providers inject services into the dependency injection system, making them easier to access across the application. Packages which are Laravel specific usually include a service provider, which ensures that the packages classes are loaded when required and available to your controllers.
Services (http://laravel.com/docs/5.0/structure)
The Services directory contains various "helper" services your application needs to function. For example, the Registrar service included with Laravel is responsible for validating and creating new users of your application. Other examples might be services to interact with external APIs, metrics systems, or even services that aggregate data from your own application.
Providers
The Providers directory purpose is basically binding the custom files with app, for example if we want to work with the repository pattern and use eloquent instead of write queries in models then we need to bind our repositories with service providers and register service provider in to config/app.php file.
Related
I am reading spring micro services for next project. Tut said that "The architecture style the main application divided in a set of sub applications called microservices. One large Application divided into multiple collaborating processes.". So already we have a framework maven multi module There I separated the project in my experience. even though it is. why do we need micro services to separate a project?. please differentiate it. thanks in advance..
Every service in the microservice architecture should be isolated which means that the team in charge of that service is able to put continuous deployment in practice without need to deploy other services. In practice, IMHO I think that we can use two approaches using our favourite build tool such as maven or gradle:
Monoproject: domain, repositories, services and controllers are all in the same project.
Multiproject: domain, repositories, services and controllers can be grouped in different modules. i.e domain and repositories are in repository module and services in another module with the same name and controllers in front module.
But, doesn't matter which approach you use the project (mono or multi) should represent one service.
I want to spread my grails application into several modules.
For example,
i want to cteate one CoreModule it will has domain classes and
base services.
Then AdminPanelModule and RestServiceModule.
They will has own controllers and own specific services. But they
have to get access to CoreModule's domain classes and services.
Than I want to deploy 2 CoreModule apps, and 1 AdminPanelModule app on different hosts. Help me plz.
How can I organize dependencies with Idea?
What i need to do, to create correct run configuration?
I have a User entity and apart from default fields/methods (I took the whole content from grails docs) I added fields like address, number etc. (Strings).
Now I rebuilded the whole project, deployed and I still don't see those in Spring Security Management Console.
How to force Spring Security Management Console to show my custom User fields?
I'm going to assume a couple of things when authoring this answer:
What you meant by the first part of the question is that you have added fields to the User domain class that was generated by the Spring Security Plugin
You are speaking of the Spring Security UI Plugin when you say "Management Console"
With those two assumptions in mind, you need to take a look at this documentation. Simply adding the fields to the Domain class will not affect the UI plugin, as the plugin has pre-defined views and controllers for dealing with the default fields in the domain object.
You need to "override" these views and controllers to support your new fields. From the sounds of it, running this script should "extract" the views and controller you need:
grails s2ui-override user <controller_package>
Where the controller_package is the package you would like the new UserController class to be a part of.
We have to support at least 2 versions of functionality at the same time. It can be in the web side or services, meaning we'll have different layout for different users in the web or service implementation will be different for different users. We should be able to route the users based on their login to the right version of the web application / bundle.
We thought of something like this (please see bigger picture here http://i.stack.imgur.com/6NxhF.png).
Also is it possible to have multiple web applications / bundles deployed as one EBA? If yes, is it possible to share the session between these web apps / bundles? As we are new to OSGi, looking forward to any suggestion on the design we have chosen. Appreciate any help / suggestions on this.
Thanks,
Bab.
OSGi could be right for you. In my last project we had something equivalent to your approach. We've developed a backend system with OSGi where we had a backend connector as a starting point for different other bundles who wants to use functionalities of the backend. In your case the backend is your shared bundle context. We then had a SOAP webservice, several servlets and webpages (which should be OSGi based as well) which sends requests to the backend connector. Of course you can send request directly to internal bundles like your manager, but I would propose a layered architecture. In case of shared sessions: The question is which component is responsible for handling sessions? If you want to have not only web applications in your environment, you can manage sessions via a database or an inmemory approach. A 'SessionManager' bundle in your shared context is then responsible for creating user sessions (sessionid for identification), relating sessionid and temp data, getting data for sessionid and deleting temp data for sessionid. With this approach each client request should send the sessionid, which will be validate somewhere in your shared context. Then you dont need the web sessions. The created sessionid could be stored in a specific HTTP header entry of Request/Response for the communication. But thats only one approach.
Hopefully, all above makes sence to you. If not send me an email and we can discuss it more in depth. :) Sometimes pictures say more as a lot of sentences and I could draw some if you want. ;)
Greetings.
Christian
Yes, OSGi can help you a lot with this.
The architecture you have chosen looks fine, I would suggest perhaps also adding a 'SessionManager' as suggested by Christian.
Regarding the OSGi specifics you will need for this:
If you have two different versions of the "Services" bundle, which are packaged in the same Java packages, you should definitely define package versions when exporting them in the manifests:
In Services V1:
Export-Package: com.acme.foo;version="1.24"
and in Services V2
Export-Package: com.acme.foo;version="2.3"
You can then control which package is imported in the Web bundles by defining restrictions, e.g. like this for whole intervals:
Import-Package: com.acme.foo;version="[1.23, 2)"
The beauty of this is that due to the modularity of OSGi and the separate classloaders of the bundles both versions of com.acme.foo can be installed and used in the same system. You cannot achieve this in the "usual" Java setup, because there there is only one classloader and one version of the package will shadow the other.
You can see OSGi demos and examples for example here
This was about the packages and libraries.
Now about the actual service objects:
You could also have two versions of the same service published in the OSGi Service Registry. The easiest way to differentiate between the two is to use service properties when registering the service:
Hashtable properties = new Hashtable();
properties.put( "service_flavour",
"advanced" );
context.registerService(
SomeService.class.getName(),
this, properties );
You can then use the props to lookup the correct service in the Web bundles:
ServiceTracker someServiceTracker = new ServiceTracker(bc, "(&(objectclass="+SomeService.class.getName()+")(service_flavour=advanced))", null);
someServiceTracker.open();
Regarding your question about EBA - I am not sure what you mean. You can install as many bundles as you want in any OSGi framework, and they can all register under different aliases in the OSGi HTTP service. As long as the aliases don't have a conflict with each other it is ok. You can also have one main servlet if you want, and distribute the handling of the different pages to other bundles without registering them as servlets too - your main web servlet could look them up in the OSGi service registry for example, and distribute the work. It all depends whether you expect more application logic/calculations etc, or is it more about formatting and representation of some existing data.
Hope this helps.
Could anyone please give some examples of possible service. I am going through the book, but cannot understand what can the service do? It provides processed data for modelAndView to controller, but what it looks like is it java bean connecting and retrieving results from database, what can it be?
A service component is where all your DAOs come together and have the business logic. You can think of it this way.
DAO - should only load data from db. Nothing more.
Services - can use daos to load multiple objects and do some kind of business logic
controllers - use services to load objects. They should have nothing more than simple logic because complicated logics should really belong in the service. Reason for this is in the future when you want to reuse this logic, you can do so if its a in service but not if its in the controller.
Example:
BookDAO - Loads the book
BookService - loads the books for a person that is logged in
Finally, I'd like to quote the grails doc for a clean concise quote.
As well as the Web layer, Grails
defines the notion of a service layer.
The Grails team discourages the
embedding of core application logic
inside controllers, as it does not
promote re-use and a clean separation
of concerns.
An example of an Service could be an Email Service in an Business Application (not in an Email-Client). This Service offer other Components the functionality (service) to send emails to notify users about stuff.