I will develop a new app (Maybe using Laravel or Rails). The point is that we will have our database with let's say user table so at application level, we will have a User model. When User model change, we will send a notification to another external source instantly. In the future the app must allow switch the external source.
I think that a good option is create a UserService (Service layer design patter) class to wrap the logic (keeping data in sync) and then all controllers will use it.
What do you think about it's the best way to do it?
I only have experience with Laravel so I'll be speaking for Laravel.
Laravel provides pretty much this - out of the box. It provides events for Model methods, such as saving, saved, created, creating... So it's extremely easy to set up service-level notifications on any of those events. It's also really easy to define your own events, if you need more specific triggers.
However, since you're doing this on application level, you will need to make sure everything is saved through your application's models. Say, if someone was to edit some data directly through SQL, it would bypass the events. So you need to make sure that everything (for example a mobile app connected to your service) is saved through your application.
Another option would be to use some database that provides that functionality (PostgreSQL out of free ones). But judging by "In the future the app must allow switch the external source." it's exactly what you're trying to avoid.
Related
I am relatively new to the UI5 Framework and I have a new use-case in my company that I want to implement with UI5 and OData Services.
Basically the application has two functionalities with different stakeholder:
Role A is able to create new requirements
Role B is able to check the requirements and update them with new
information
How can I implement this the best way? My previous thoughts on that:
Possibility 1:
I have the OData Service in the Backend that is used by two separated application depending on the role. The access is controlled through the launchpad over the PCFG objects. So a specific user can only use the application that he actually needs. I believe that matches the basic granularity of Fiori apps. On the other hand, it invalidates the DRY principle since I would have redundant code like most of the view.
Possibility 2:
I check in the UI5 Framework or OData Service which user is currently using the app and enable/disable the required controls in the controller class. I haven’t come across on how to do this. Is there a way to check which user is logged on? Or how can I implement in the OData service, that only specific information is delivered to the client?
What is the correct way to implement such a use case? Is there a better option that I am not aware of? I would appreciate any thoughts on that matter, thanks :)
Best regards
Suggested Approach
If two roles do not share any common functionalities, then I would go for two separate UI5 apps, so as to keep them simple. In that case, each app would have it's own OData service. But in the backend, you can always have a common class for 'Requirements' which is called by both the OData service implementations. (So as to maximize code reuse). So most of your business logic should be inside the 'Requirement' class, and the OData implementations serve as dispatchers.
To check which user is logged in
This is a common requirement for most of the business applications and it is possible in Gateway/ABAP as well. Within the ABAP context, there is always a system variable available named SY-UNAME, which will provide you the current logged in user's name. You can use it further to derive the user's role.
We have a fairly complicated framework (made up of multiple plugins) that we've developed for all of our future Groovy/Grails applications. One aspect of this framework is the ability to retrieve user information from the various systems that we store this data in. Currently we have three classes that represent a user (one for LDAP (non AD), one for AD, and one for database). The reason for three separate classes is because they access totally disparate systems and are based on different base classes to provide various functionality need to access these systems. There's also dependencies, etc. that require this three class approach. One of these classes (the one for AD) is also used by Spring Security to represent a user. It is also possible to create any user object type from another user object type.
What I'm trying to create is a way for us to cache these objects. For example, during login, one class is always loaded (by Spring Security). However, throughout the process of using the application, another class (for database info for example) might get loaded temporarily. Ideally I'd like to cache these objects (that all represent the same user) so that we don't have to reload information.
In the end what I'm hoping to accomplish, is the ability to pass one user object (say AD) to another user class (say database) factory method, and have the database user class check if it has ever existed before for this user and if so, instead of recreating itself, just grab the cached copy. I'd rather not use a central cache to do all of this caching, but instead store the cached information in the actual objects (just seems cleaner that way).
What I can't figure out though is how to accomplish this (from a design perspective). So I'm looking for recommendation on which design patterns might help me to figure out an approach to creating this functionality.
P.S. Just in case it matters, all user classes extend different base classes, however, they all implement a shared interface.
Sounds like the appropriate caching at the various services that are responsible for looking up the related User instances would be the most appropriate approach. Using the Cache plugin would make this quite trivial.
Your factory method could delegate to the appropriate service method which would be annotated with the correct cache. Just keep in mind that you will need to invalidate items in the cache as well if they are subject to changes.
Having a bit of an issues on design, and was hoping I could ask for advice here. Accept that grails may be the completely wrong tool, but such is life.
So have been working away on a web app that basically just present a lot of information from a google spreadsheet and sends some updates back. I have managed to get most of it working but decided to rewrite it to get rid of my ridiculous spaggeti code as well as the many pieces of broken code that lays strewn throughout the project.
The system is relatively small, two-three users. The amount of data is small as well. One worksheets with max 500 rows (four columns) and another one with potentially 5000 (four columns). So all small, but I need it (well, want it) to stay in the google spreadsheet and the application feeding from there.
There are three classes I need for this to work,
Google authentication class keeps information on keys and tokens to speak to google
Google Spreadsheet class keeps information on the source spreadsheet
Google Data Entry keeps information from the two spreadsheets based on a unique id
So here is my question, what should I define these classes as. Thought I would use Domain classes, but then realised that these are stored in a database. Is there a way of keeping domain classes session dependent, I.E., that two users can use the same app on the same server but never see each others data and that the data is destroyed on logout. If not, is there some other class I can use that works similar to Domain class but kept in memory user/session specific.
I'm not really sure what exactly your requirements for those classes, but here are some thoughts anyway.
First, you may want to ask if they can't just be "normal" classes in src/groovy. I say "normal" here in the sense that they may just encapsulate some data and behavior, and you are responsible to create instances of them and call the methods appropriately when needed.
But, if you want to tie some data and behavior to the user session (as you seem to, because you asked for session dependent domain classes), you may want to use a Grails Service with session scope. When you do that, Grails will use a different instance of the service for each session of your application, and reuse the same instance for the same session until it ends.
You may also use a bit of each thing, using one service with session scope and have other classes representing the data that you pass around from the controllers to the service and vice-versa. These could actually be Command Objects if you needed validation and data binding, for example.
I'm new to Grails and web development. I started doing a project on Schedule management website stuff. I came across the Service concept that is provided by Grails. I understood the concept, but still I have confusion on when to use services.
For example, I need to implement a search module, where the manager can search for a user to find his schedules. In this case it will be good to implement it as a controller or as a service?
So,
When and where should I use Service?
To add to Grooveek's answer;
It is also nice to use Services to keep your Controllers nice and clean.
So Views just render data to the screen, Domain objects store state, Controllers route the user around the application, and Services perform the work.
I don't have enough reputation to comment on an answer or vote up so I have to provide an answer that really should be a comment. Anyways...
+1 on #tim_yates answer. Gotta love thin controllers. 2 things that I would add to the description of a controller:
Would be to translate parameters from the browser before hitting a service (e.g. Date, number, etc.)
Would be to translate data returned from services into something consumable for the views.
For me, ideally, services would never deal with translating a String parameter to it's inherent type. Or deal with building a model to be displayed on a view.
What and where I should use Service?
When you want your controller do to something that may be reused by other controllers
In our application we're doing a functional separation of service. We have a CorePersistanceService, which provides method to create, delete, update and manipulate Core Domain Classes (core for us).
I think persistance services are a good way to reuse GORM code throughout Grails code. You can create method in domain classes, but I don't like that, it's way less maintanable I think
We have a PDFService class for our PDF creation, a SolrService which connect to Solr, a Statisticservice that gather all our methods which collects statictics on our datas
Services in Grails are a manner to gather methods around a particular functional theme, in order to give possibility to reuse them in controllers (I forgot to mention our SecurityService, which is a pretty good Cross-Applications Example)
Problem: Our web console shows a list of all computers on which our application is installed. Each machine has some identification information that can be associated with it. Simple strings like department name, team name etc. We need to make it such that the user can change the name of these identification fields and add/remove as many as he wants. How can we best implement this?
Initially i thought that i could implement this as a singleton. In the application start, i could read the last set identity field names from the db and create a singleton instance of a list of strings. This could be passed around to all functions that need to display or access the identity information. The appeal in this option is that if the user changes the identity fields name from the ui or adds or removes the fields, i can simple modify the singleton object and the change will be reflected.
However i feel there must be a better way to achieve what i want. Because there a lot of such information that the user can modify at will and we need to track them.
Any suggestions?
Just use the objects from your ORM to maintain and use this information in the application. Many ORMs have the ability to cache this sort of thing, so it's not like you will lose any speed over it.
I'm not a big fan of using a Singleton to do this. It's hard to unit test, and you'll still have to persist it to the database eventually.