I have to spend a lot of time learning and implementing Livedata (especially MediatorLivedata) in business logic because it helps to add data from various sources. Had a success with it, because I could add FCM, Network or RoomDatabase as different sources to my MediatorLivedata and observe it in ViewModel. Its actually scales very well. However, it still lacks powerful RxJava2 implementation, like chaining requests well, flat map and etc. It seems that RxJava is used primarily in Business logic, but in fact, I saw a lot of companies using RxJava with UI with additional features/libraries. This actually makes LiveData irrelevant in presentation logic. So I would like to know if LiveData is somehow better/cleaner in presentation logic(using it in a ViewModel) vs RxJava. What would you suggest looking into the future?
RxJava is neither better nor worse to LiveData, it is different.
Android Architecture Components was designed to give a model architectural pattern to android developers. So, if you're comfortable with LiveData, use that, or if you're comfortable with RxJava, use that. You can do all operations using both libraries.
Though RxJava do contain a lot of syntactic sugar, same can be achieved using Livedata also.
I think you can use RxJava and LiveData altogether. RxJava will use to under Model layer, use it for the request and receive data from the server or from the local database.
Then the LiveData will be registered to the Activity/Fragment because with LiveData you can handle the Activity/Fragment life-circle easily, and it was designed for that purpose.
Related
Which kind of design pattern speaks for and which against having an interface on every Service in Spring / SpringBoot?
Or does it only make sense to use Interfaces for services if at least you use two different implementations for a given interface.
What is the advantage to use an interface if you only have always one implementation in your code base.
I can answer your question with: it depends.
If you think about the SOLID principles, especially the Interface Seggregation, and its importance in object-oriented design:
Within object-oriented design, interfaces provide layers of abstraction that simplify code and create a barrier preventing coupling to dependencies.
The interfaces are using to expose the API contracts without exposing their implementation.
But, as I said before, it depends on the use case.
Let's say you're building a library/framework where it can expose multiple implementations for the same interface or allow the users to add their implementations. Then you surely should have interfaces.
On the other hand, it can also lead to some overengineering where your interface has only one implementation, you are sure it won't have more than one implementation, and it won't be used outside of your application. Then maybe you could skip it.
So, from my point of view, it depends.
I'm building application at top of the Laravel. In my Domain layer I have services. One of these needs to send an EMail. Laravel has Illuminate\Mail package for these purposes.
But Mailer contract depends on \Illuminate\Mail\PendingMail class.
https://github.com/laravel/framework/blob/5.7/src/Illuminate/Contracts/Mail/Mailer.php
Does it mean I need to write my own interface (port) for my Domain layer to fully decouple my application from framework?
To be honest, I'm not sure what you are asking. But I'll try to answer anway.
If you use (any) framework functionality directly in your code, you obviously couple your application to the framework. That's the whole point of a framework. It offers you a lot of functionalities that are commonly used throughout different types of applications. It can be seen as foundation for an applciation. These functionalities are often made available through interfaces, so that the implementation can be swapped out if necessary. Swapping out the implementation doesn't make your application less coupled to the framework though. It just allows you to use a different kind of implementation; the interface will still be a framework one.
So, the only way to prevent (heavy) coupling with a framework would be to write your own interfaces that abstract all the framework functionalities. You could then have proxy classes that implement these new interfaces and do nothing else than proxying requests to the proper functions of the framework, allowing you to write other proxy classes in future for a different framework.
If you ask me, this sounds like a bad idea though. Because in the end, you are building your own framework based on your own interfaces. So you are using additional custom code which adds no additional functionality, but comes with the added risk of bugs and errors.
I want to implement a Spring Data Repository for a database which is not currentlty supported (hyphothetical question - no need to ask about the database).
How is this possible and where can I have an example of that?
Short answer is "yes, definitely". One of the main Spring-data's intentions is to unify access to different data storage technologies under same API style. So you can implement spring-data adapter for any database as long as it is worth implementing a connector to that database in Java (which is definitely possible for the majority of databases).
Long answer would take several blog posts or even a small book :-) But let me just highlight couple of moments. Each of the existing spring-data modules expose one of (or both) the API flavors:
imperative - in a form of various template classes (e.g. RedisTemplate). It is mostly for the databases that don't have query language, but only a programmatic API. So you're just wrapping your db's API into template class and you're done.
declarative - in a form of so called Declarative Repositories, quite sophisticated mechanism of matching annotations on method signatures or method signatures themselves to a db's native queries. Luckily spring-data-commons module provides a lot of scaffolding and common infrastructure code for this, so you just need to fill the gaps for your specific data storage mechanism. You can look at slide deck from my conference talk, where I explained on a high level the mechanics of how particular spring-data module generates real implementations of repositories based on user declarations. Or you can just go into any of the existing modules and look into source code. The most interesting parts there are usually RepositoryFactory and QueryLookupStrategy implementations.
That is extremely simplified view of the spring-data concepts. In order to get more detailed information and explanations of core principles, I'd suggest reading spring-data-commons reference documentation and having a look at spring-data-keyvalue project, which is a good starting point to implement Spring Data Module for key-value storages.
I've started using EF and LINQ in a project and I'm trying to decide on the best approach/pattern to use. Until now I've been using a custom persistence framework that was based on DataSets and XML configuration. Basically it was a VS Custom Tool that would read the XML configuration file and the DataSets and would generate Object Oriented classes with all the necessary properties/associations/methods. This auto-generated classes then were used from the UI and I had the flexibility to expose only what the UI would need.
Now with EF and LINQ, I'm not comfortable with the idea that the UI can use directly the auto-generated classes and all the LINQ stuff. It seems that this approach would have a very tight integration between UI and the database.
So I'm looking for some pattern that would "hide" all the EF and LINQ goodies and basically limit what the UI can do. Is there any standard way to do this?
What you're looking for is an n-tier application. It's not so much a pattern as an architecture. You break your app up into 2 or more pieces, typically 3 composed of UI, business and Data. You might implement this through other patterns such as the Facade or Repository patterns to keep a strong seperation of concerns.
You might also use a Service Layer, which could be implemented by a facade or as a web service.
You would, ideally, pass data through objects called DTO's or Data Transfer Objects, and you might adapt those DTO's by using a view model in your UI (not to be confused with MVVM which another poster erroneously mentioned.)
Beyond that, much of it depends on the type of app you're buiding. Desktop app, server app, web app, etc..
The pattern you're looking for is, in general, Model-View-ViewModel, or MVVM.
Here's a tutorial that seems to hit on the high points of the design pattern: http://csharperimage.jeremylikness.com/2010/04/model-view-viewmodel-mvvm-explained.html
I am a big fan of Dependency Injection and the Play Framework, but am having trouble seeing how the two could be exploited together.
There are modules for Spring and Guice, but the way that Play works makes it hard for me to see how DI could be beneficial beyond some quite simple cases.
A good example of this is that Play expects JPA work to be done by static methods associated with the entity in question:
#Entity
Person extends Model {
public static void delete(long id) {
em().find(id).remove();
}
//etc
}
So there is no need for a PersonManager to be injected into controllers in the way it might for a Spring J2EE application. Instead a controller just calls Person.delete(x).
Obviously, DI is beneficial when there are interfaces with external systems, as the concrete implementation can be mocked for testing etc., but I don't see much benefit for a self-contained Play application.
Does anyone have any good examples? Does anyone use it to inject a Manager-style class into Controllers so that a number of operations can be done within the same transaction, for example?
I believe from this sentence you wrote:
"Does anyone have any good examples? Does anyone use it to inject a Manager-style class into Controllers so that a number of operations can be done within the same transaction, for example?"
that before answering the DI question I should note something: transactions are managed automatically by Play. If you check the model documentation you will see that a transaction is automatically created at the beginning of a request, and committed at the end. You can roll it back via JPA or it will be rolled back if an exception is raised.
I mention this because from the wording of your sentence I'm not sure if you are aware of this.
Now, on DI itself, in my (not-so-extensive) experience with DI, I've seen it used mainly to:
Load the ORM (Hibernate) factory/manager
Load Service classes/DAOs into another class to work with them
Sure, there are more scenarios, but these probably cover most of the real usage. Now:
The first one is irrelevant to Play as you get access to your JPA object and transaction automatically
The second one is quite irrelevant too as you mainly work with static methods in controllers. You may have some helper classes that need to be instantiated, and some may even belong to a hierarchy (common interface) so DI would be beneficial. But you could just as well create your won factory class and get rid of the jars of DI.
There is another matter to consider here: I'm not so sure about Guice, but Spring is not only DI, it also provides a lot of extra functionalities which depend on the DI module. So maybe you don't want to use DI in Play, but you want to take advantage of the Spring tools and they will use DI, albeit indirectly (via xml configuration).
The problem in my humble opinion on the static initialization approach of Play! is that it makes testing harder. Once you approach the HTTP vs Object Orientation problem with static members and objects that carries the HTTP message data (request and response) you make a trade of having to create new instances for each request by the ability of make your objects loosely coupled with the rest of your project classes.
One good example of a different design are servlets, it also extends a base class but it approaches the problem with a single instance creation (by default, because there are configurations that enable more instances).
I believe that maybe a mix of the two approaches would be better, having a singleton of each controller would give the same characteristics of a full static class and would allow dependency injection of some kinds of object. But not the objects with request or session scope, once the controller would need to be created every new request. Moreover it would improve testability by inverting the control of dependency injection, thus allowing arbitrary injection points.
Dependencies would be injected by the container or by a test, probably using mocks for the heavy stuff that much likely would already have been tested before.
In my point of view, this static model pushes the developer away from testing controllers because extending FunctionalTest starts the application server, thus paying the price of heavy objects like repositories, services, crawlers, http clients, etc. I don't want to wait a lot of objects to be bootstrapped just to check if some code was executed on the controller, tests should be quick and clear to make developers love them as their programming assistant/guide.
DI is not the ultimate solution to use everywhere... Don't use DI just because you have it in your hands... In play, you don't need DI to develop controllers/models etc... but sometimes it could be a nice design: IMO, you could use it if you have a service with a well know interface but you would like to develop this service outside Play and test it outside play and even test your play project with just a dummy service in order NOT to depend on the full service implementation. Therefore DI can be interesting: you plug the service loosely in play. In fact, this is the original use case for DI afaik...
I just wrote a blog post about setting up a Play Framework application with Google Guice. http://geeks.aretotally.in/dependency-injection-with-play-framework-and-google-guice
I see some benefits, especially when a component of your application requires a different behavior based on a certain context or something like that. But I def believe people should be selective about what goes into a DI context.
It shows again that you should only use dependencies injection if you really have a benefit. If you have complex services it's useful, but in many cases it's not. Read the chapter about models in the play-documentation.
So to give you an example where you can use DI with play. Perhaps you must make a complex calculation, or you create a pdf with a report-engine. There I think DI can be useful, specially for testing. There I think the guice-module and spring-module are useful and can help you.
Niels
As of a year and some change later, Play 2.1 now has support for dependency injection in controllers. Here's their demo project using Spring 3, which lays it out pretty clearly.
Edit: here's another example using Guice and Scala, if that's your poison.