On sails.js official documentation on services it says "Although Services are still fully supported in Sails 1.0, it is recommended that you use helpers instead.".
When should I use service vs helper? What is the core difference between them?
A service is a singleton instance which is present all the time. There is just one single instance for all calls. You could use this if you want to let mutiple requests or sockets communicate with each other.
A helper is like a function. Every call of it is independent from others.
(As long as you don't use global variables)
If you are using services, you should be very careful because the same instance is called by different users.
Related
I don't have Gateway available in my landscape and I want to use the ABAP REST library to expose web services: SAP Library - REST Programming Tutorial
With a very simple example, I successfully created a class to read a single domain list of values, the GET call is quite simple:
http://mydomain/domainvalues/XFELD
And the GET implementation is in my class ZCL_REST_DOMAIN_VALUES extending from CL_REST_RESOURCE implementing IF_REST_RESOURCE~GET method.
Now I want to make it possible to read or query multiple domains. I'm not an expert in REST but I've seen two options searching around, one using the same URI as the single entity and one with special URI for queries.
http://mydomain/domainvalues?Id=XFELD,WERKS_D
http://mydomain/query/domainvalues?Id=XFELD,WERKS_D
In the backend, should I use the second approach and create a class only for this call named for instance ZCL_REST_DOMAIN_VALUES_QUERY implementing the GET method again?
Or maybe should I use POST method to send the list of IDs to fetch in the body?
SAP's own in-house guidelines recommend to shape OData and plain REST services alike, to avoid confusion and facilitate switching between the two:
http://mydomain/domainvalues?$filter=Id in ('XFELD', 'WERKS_D')
Both would be served by the same REST endpoint handler class, although of course you are free to create separate methods or delegates for the cases.
Remember to sanitize (= whitelist/blacklist/escape) the query parameters before handing them over to some lower level to prevent SQL injection attacks, as #SandraRossi correctly pointed out below.
My layout
project.web (.net core 2.1 web api)
Some binding models (for post/put requests) and resource models for GET requests
Controllers.
I only call interfaces from (x.api) which are resolved to x.core services.
No validation or anything. This happens inside the core layer
I've setup a few things like automapper and swagger, that are not relevant for my question.
project.api (class lib)
only contains interfaces for .core and .store projects (services, repositories and domain models)
project.core (class lib)
two kinds of services
1) Services which call the repository services (interfaces). But validate the data before calling the repo service.
2) Services that will have to execute long term stuff (IE: scanning folders, handling file information, ...). I actually created HostedServices for these as a folder could easily contain thousands of files.
project.store (class lib)
Wrapper services for my storage (Only contains helper methods so I don't have to write the same queries a hundred times.)
Problem / question
At this time I have registered all of my services and repositories as singletons in public void ConfigureServices(IServiceCollection services)
because I was using a different storage (nosql, litedb) before refactoring code to EF (sqllite)
Now the problem is that I want to register my DbContext as scoped (by default)
But my repositories (singleton) depend on dbcontext. Which means I will have to make these scoped as well. I'm ok with this, as these are only wrapper services, so I don't have to write the same queries all the time.
But some other services, that will need access to my data are singletons, and I cannot register these as scoped. Contains some data that needs to be the same for every request, and some collections and long running jobs.
I can think of two solutions
The first solution is to make a dependency to IServiceScopeFactory in my repository and use something like using (var scope = ServiceScopeFactory.CreateScope()) { scope.ServiceProvider.GetService(typeof(MyDbContext))... }
this way I can remove the dependency from my repository wrapper, but this doesn't sound clean to me.
The other solution is to register all of my services that only handle database stuff as scoped. (IE customerSservice in core only does validations and calls customerRepository) I remove dependencies from my remaining singleton services.
In those singletons, instead of depending on the customersService, I could use a rest call with restsharp or something similar
Just like how I would consume them from my windows client applications and web client apps.
I don't actually like either. But perheps someone can give me some advice or thoughts?
Well, the two options you laid out are in fact your only two options. The first is the service locator antipattern, which as the name implies, is something you should avoid. However, when you are dealing with singleton-scoped objects needing access to objects in other scopes, there is no other way.
The only other option is to reduce the scope of your services from singletons, such that you can then inject the context directly. Not everything necessarily needs to be a singleton. Generally, if you need to utilize something like DbContext, there's a strong argument to be made that your object should not be singleton-scope in the first place. If you need it to be singleton-scoped, that's most likely an indication that the class is either doing too much or is otherwise brittle.
I can't understand by docs what is the difference between registerRestInterface, registerWebInterface and RestInterfaceClient.
Both of them can generate methods by class. But I can't understand when I should use one and when another.
The key to understand the difference is to realize that vibe.web.rest and vibe.web.web are two different modules with a different use cases in mind:
vibe.web.rest
meant for stateless communication
requires to define an abstract interface
RestInterfaceClient can be used to communicate with other Rest interfaces
A JS client can be generated from the API interfaces
can be registered with registerRestInterface
When to use:
large public APIs
API needs to be shared with others
-> usage example
vibe.web.web
intended for web services
allows direct access to the current session and request context
provides many convenience functions based on the request (e.g. redirect)
allows #auth (example)
can be registered with registerWebInterface
When to use: web services, small APIs
-> usage example
I personally use vibe.web.web more often as for my small projects the overhead of keeping the interface files in sync isn't worth it.
Moreover, I like the convenient access to the request context and session variables in vibe.web.web. In fact, I maintain a drop-in fork that adds more convenience feature (auto-serialization to/from Json, auto route /:param/ generation based on the method params, ...)
I am bit confused about services in DDD.
First of all. Why are services always expressed as an Interface? Is that a rule?
Why do services contain only one method? Sometimes it makes sense to implement related methods in a single class.
Do I have to make services for each repository? I must be doing something wrong because I find myself making services for CRUD operations.
For example I have a repository with the usual methods. How do I control the access to the objects persisted in the repository? I tend to make services with lots of reading methods. Those services can check the user roles and then decide if the user can use the objects or not. I feel something is not good in my design.
I'm assuming you're talking about domain services. There are other types of services in DDD such as application services and infrastructure services.
First of all. Why are services always expressed as an Interface? Is
that a rule?
No this is not a rule. Only create an interface abstraction when there is a need for it.
Why do services contain only one method? Sometimes it makes sense to
implement related methods in a single class.
A service with a single method can be thought of as implementing a single operation - a single use case. If it makes sense to encapsulate multiple operations in a single object than this is also acceptable. However, conflating multiple responsibilities into a single class often leads to violation of SRP.
Do I have to make services for each repository?
No. A repository is already a sort of service. More specifically, a repository implementation can be thought of as an infrastructure service.
It is the application service which calls a repository in order to implement some use case. It delegates to domain entities and orchestrates other services that may be required for a given operation. Take a look at Services in DDD for an example of the various services interacting.
Is it appropriate to expose a ReactiveCollection in an API? Specifically, in a service class that would be used internally on multiple applications. But as a thought experiment, we can also consider in public use as well.
I've been investigating Rx and ReactiveUI, and these seem like powerful tools. However, I don't have enough experience with them to determine if it is a good idea to require others to take a dependency on them.
More details:
I'm creating a tracking service class that would track connected clients. From my view, all that would be necessary for consumers to use this class is to expose an observable collection (possibly a ReactiveCollection) that exposes the connected clients, and notifies of changes to the collection which are managed by the service. The entitity representing the connected clients would also take advantage of INotifyPropertyChanged to notify of updates to the clients' state.
Since ReactiveCollection is a derivative of .NET's ObservableCollection (i.e. the non-Rx WPF/SL one), you could expose it as an ObservableCollection instead.