Let's say I have some codes to make 2 rest calls to the other API. And I need a service layer to make 2 rest calls in the same action.
In Java, I probably would do something like this
#Service
public class RestService{
#Autowired
RestClient restClient
def shutdown(){
if(restClient.isSystemGood()){
restClient.shutdownSystem()
}
}
}
#Repository
public class RestClient {
boolean isSystemGood() {
...
}
void shutdownSystem() {
...
}
}
How should I fit in grails way to do the similar thing?
Should I put the logic inside RestClient into a domain class? or Should I put both RestService and RestClient into a domain class? Does domain class have to be backed by a DB?
Because I only see service and domain folders in the grails default file structure.
RestService (in your simple case a non-transactional one) inside grails-app/services directory is the right place for the logic. Inject the service inside the controller action to use it.
Injecting services into the domain class is not recommended. It hard to test, degrades the read performance and results in a spaghetti design. This is why Grails now by default, has disabled the services injection in the domain class
Related
I'm new to asp.net mvc world mostly a windows developer moving to web. Be nice...
I found ridiculous when I look at many examples of asp.net mvc web applications that the pass to their controllers a list of services
Like this
public CustomerController(ICustomerService customerService,
IAnotherService anotherService,
IYetAnotherService yetAnotherService,
IYetAgainAnotherService yetAgainAnotherService,
etc...
Would not be better to do something like
public CustomerController(IServices services)
{
}
public interface IServices
{
ICustomerService CustomerService{get;set;}
IAnotherServiceService AnotherService{get;set;}
IYetAnotherServiceService YetAnotherServiceService{get;set;}
}
Am I missing the obvious?
As anybody implemented the way I suggest in mvc4 or mvc5. I know mvc6 does it.
But I cannot use mvc6 at work.
Any samples using DI?
Thanks
What you're missing here is the fact that constructors with many parameters is a code smell often caused by that class having to many responsibilities: it violates the Single Responsibility Principle.
So instead of packaging the services to inject into a 'container' class that allows those services to be accessible using a public property, consider the following refactorings:
Divide the class into multiple smaller classes.
Extract logic that implements cross-cutting concerns (such as logging, audit trailing, validation, etc, etc)out of the class and apply those cross-cutting concerns using decorators, global filters (MVC) or message handlers (Web API). A great pattern for your business logic is the command/handler pattern.
Extract logic that uses multiple dependencies out of the class and hide that logic behind a new abstraction that does not expose the wrapped dependencies. This newly created abstraction is called an Aggregate Service.
I agree that for readability sake, even if you have multiple existing services which are also used in other applications, you could always wrap them in another class to avoid passing a long list of dependencies to the controllers.
When you have code in the API controllers that look like this:
public CustomerController(ICustomerService customerService,
IAnotherService anotherService,
IYetAnotherService yetAnotherService,
IYetAgainAnotherService yetAgainAnotherService,
...
That can be a code-smell and is an opportunity to refactor. But this does not mean the original code was a bad design. What I mean is in the API layer, we try not to clutter it with too many services that the controller is dependent on. Instead you can create a facade service. So in your example above, you refactor it to look like this:
public CustomerController(IServices services)
{
}
public interface IServices
{
ICustomerService CustomerService{get;set;}
IAnotherServiceService AnotherService{get;set;}
IYetAnotherServiceService YetAnotherServiceService{get;set;}
}
Which is good and then you can move the IServices to your service/business layer. The concrete implementation of that in the service/business layer will look like this:
public class AConcreteService:IServices {
public AConcreteService(ICustomerService cs, IAnotherServiceService as, IYetAnotherServiceService yas)
{
...
}
public List<Customer> GetCustomers(){
return _cs.GetCustomers();
}
public List<string> GetAnotherServiceData(){
return _as.AnotherServiceData();
}
public List<string> GetYetAnotherServiceData(){
return _yas.YetAnotherServiceData();
}
...
So that code will end up looking like your original code when implemented directly in the controller but is now in the service/business layer. This time it will be easy to unit test in the service class and the API layer will look much cleaner.
I have a requirement, my current project is with ejb3, jpa and jsf. I have a core development project and customer specific project. In the customer specific project, we planned to inherit the core classes and extend or override the core functionality. So we planned to create the customer specific classes with some customer prefix. So in the final war file, we will have the core class and all customer prefix classes. For example, if Authenticator is a core class and XXAuthenticator, YYAuthenticator are customer specific classes exist in the build. So, for example if i have a line of code in a bean like this:
#Inject Authenticator authenticator;
Can i programmatically and/or dynamically inject the inherited classes based on some logic like logged in user has a customer specific functionality.
what i am expecting is, i dont want to change the above line to inject, because it will be big change in every class. But expecting some kind of dynamic logic or configuration file to change the core class injection to customer specific class..
So finally with out touching the #Inject Authenticator authenticator; line. Can I inject the xxAuthenticator or YYAuthenticator through some logic? We dont have Spring in project technology stack.. So please suggest me with out spring only.. Thanks in advance
It sounds like your use case is more around Qualifiers. If a user follows a certain, you should be injecting different qualified versions of classes to use, no?
#Inject
private Instance<SomeService> someServiceInstance;
// later on...
SomeService someService = null;
if(someCondition) {
someService = someServiceInstance.select(new FooLiteral()).get();
}
else {
someService = someServiceInstance.select(new BarLiteral()).get();
}
Where FooLiteral and BarLiteral are annotation literals for #Foo and #Bar, which are qualifiers.
In CDI this is done with "producer methods".
It would look like this:
#ApplicationScoped
public class AuthenticatorProducer {
private Authenticator xxAuthenticator; // = ...
private Authenticator yyAuthenticator; // = ...
#Produces
public Authenticator getAuthenticator() {
if (someCondition) {
return xxAuthenticator;
} else {
return yyAuthenticator;
}
}
}
No need to change injection points and Authenticators don't have to be CDI beans themselves.
When you generate controllers in grails, the controllers call methods on the domain layer directly - I quite don't understand this, every bit of me is telling me that this is kind of wrong because you are tightly coupling the backend with the frontend. I think this belongs to the service layer.
Since it would be pretty ugly to create an equivalent set of methods in the service layer for all the methods defined on domain objects, I created this AbstractService to delegate all (missing) method calls from the service layer to the domain layer:
abstract class AbstractService {
def entityType
/**
* By default, this method takes the name of the service that extends this
* class, removes the suffix 'Service' and tries to create the Class object
* from the resulting name. Override at will.
*/
protected Class getEntityType() {
if (!entityType) {
try {
entityType = Class.forName(this.class.name[0..-8], false, Thread.currentThread().contextClassLoader)
} catch (ClassNotFoundException e) {
throw new ClassNotFoundException("Class ${this.class.name[0..-8]} could not be found. Please "
+ "override AbstractService#getEntityType() for ${this.class}.")
}
}
entityType
}
def methodMissing(String name, args) {
try {
if (getEntityType()?.metaClass?.getStaticMetaMethod(name)) {
getEntityType().invokeMethod(name, args)
} else if (args?.last()?.metaClass?.getMetaMethod(name)) {
args.last().invokeMethod(name, args.take(args.size() - 1))
} else {
throw new MissingMethodException(name, this.class, args)
}
} catch (MissingMethodException e) {
throw new MissingMethodException(name, this.class, args)
}
}
}
Then I just extend this service e.g. like this:
class UserService extends AbstractService {
}
And my controllers then can look for example like this:
class UserController {
def userService
def create() {
userService.save(new User(params))
}
def list() {
userService.list(params)
}
// et cetera...
}
Don't you think this is better? Thanks to dependency injection, I can for example rewrite the whole business layer without the need to change the code in the controllers - which is kind of why we use dependency injection, isn't it?
Thanks for your answers, I would like to hear as much opinions as possible.
This model is very used in Java Web applications and all. The Rails (and Grails followed it) community just tried to break the paradigm here, leaving it more simple. I mean, why would you delegate a service class to manipulate an entity, if this entity can simply do the job? If it's natural to the entity to do the job, then don't bring someone else to do it. That way, you avoid the Anemic Model since your objects are not only data holders, but they also know how to operate its own business.
Having said that, there are times when you're better off using a service class to do operations on your entities. For example, if it involves different kind of entities at the same time and so on... So, when it's not "natural" (and you would have to force to make it work) for the entity itself to take care of the operation, then a service class is the way to go. This article based on Rails gives some tips about the use of a service class.
And you are not tightly coupling the controller with the models (you said backend and front end, but I guess that's what you mean). The controller will eventually need to use the model, be it the entity itself or a service class (also Model) manipulating it.
The scaffolded controller code does not really represent ideal application architecture. Keep in mind that the generated scaffold code is just a starting point for generating the CRUD portions of your application.
You are correct that in general, you don't want to put most of your GORM queries in Controllers, since controllers are supposed to be for interacting with the front end. You can certainly either put the query/business logic into Services or put the queries directly into Domain classes. That's why Grails Services support declarative transaction handling.
I just want to know what would be best practice/ widely used, I currently do my logging in the domain service layer, however anything that happens inside my web application layer is not logged.
I would like one centralized and simple location to do all my create/delete/update loggging...
I have heard of Elmah, not sure how useful it is for domain service layer logging only...
I currently do not use any framework for logging at all, I just string builder my log message or get the exception and flush it into the database... Is this the best way to go about it?
If it matters... I need to use Ninject to inject in my ILoggingService
NOTE: I am not talking about Logging User Activity... that will definetly reside only inside my domain service layer...
Haroon,
Leverage Ninject to create and manage the lifetime of an ILoggingService. The implementation of that service should be built directly on top of a well tested logging library like NLog or log4net.
Once you have an instance of the service, you can easily inject it into either you MVC controller or your domain layer. All logging should happen against that instance, not a static logging class.
This will allow you to have the unified logging you are looking for, with a clean separation of concerns.
imho logging should not be injected. The reason is that most of your services (if not all) will use logging.
If you look at most logging frameworks (like nlog), they are using a singleton/facade and abstract factories to provide logging.
Something like:
public static class LogFactory
{
private static ILogFactory _instance;
public void Assign(ILoggingFactory factory)
{
_instance = factory;
}
public ILogger CreateFor<T>()
{
return _instance.CreateFor<T>();
}
}
The design makes your services only dependent of one class and one interface. Thus it's still extremely easy to switch logging implementations.
In your class use the code like:
public class ServiceImp : IService
{
private ILogger _logger = LogFactory.CreateFor<IService>();
public void SomeMethod()
{
_logger.Warning("Something went wrong, but we can handle it. Hence only a warning");
}
}
In an MVC app, we the have need to create a configuration settings class that is needed throughout the app. It is a cross-cutting concern in that it is need in controllers, sometimes deep in the domain logic, as well as place like HtmlHelper extensions. The fact that it's needed is so many different places is what is tripping me up.
The class will wrap settings that are pulled from the web.config, as well as a table in a DB. The DB settings query will be cached so I'm not worried about that getting hit up for every request.
In years past I may have created some static type of class or singleton, but I don't want to lose the testability I have now. What would be the best way to instantiate this class and then to be able to access it through pretty much anywhere in the app?
I would continue to use a singleton. But a singleton which is wrapping an interface, which also makes it testable.
public class Configuration
{
private IConfiguration _config;
public static IConfiguration Instance { get { return _config; }}
public static void Assign(IConfiguration config)
{
_config = config;
}
}
Simply use Assign in global.asax or any of your unit tests.
If you want to do it the correct way, you should provide the configuration settings directly in the constructors of your objects.
Instead of
public class MyService
{
public MyService()
{
var confString = Configuration.Instance.GetConnectionString()
}
}
You would do:
public class MyService
{
public MyService(string confString)
{}
}
Finally, I would not have any configuration dependencies in HTML helpers. By doing so yuo are adding business logic to your views which breaks separation of concerns
I think the codeplex project mvccontrib provided some hooks to use
at least 3 IOC providers as far as I not windsor, structurmap, spring.net...
but I did not used it myself
you can find out more here
http://mvccontrib.codeplex.com/
and maybe you can look into the sourcecode of this project and see where you can go from there...
HTH
I would refactor my app not to use configuration everywhere. I use configuration in controllers only. My views do not have any logic, my domain model does just have business logic, not application logic.