I'm working on an application acts as an event service bus for integrating various legacy components....The application utilizes a data store to audit all events and requests sent between systems as well as to store metadata about bus-subscribing endpoints...etc. I want to utilize CouchDB as the data store since it already has many of my application's requirements built-in (REST API, replication, versioning metadata documents...etc). Now here's how my app stack looks like:
[spring-integration filters/routers/service activators]
[service layer]
[dao layer]
[database]
With the database being CouchDB, I guess the the DAO layer would be either Ektorp Java library or a simple REST client. Here's my question though: isn't building a DAO layer with Ektorp kind of redundant? I mean, why not just use a RestTemplate in the service layer that talks to the views and design documents in CouchDB and save me some coding effort?
Am I missing something?
Thanks,
I don't know if you have tried it yet, but LightCouch in many ways would act like a REST template. Beside handling document conversion to your domains, and design docs / views, you may use it as a client to CouchDB anywhere in application such as a DAO or service layer.
If you roll your own you will have to implement the json parsing / mapping of view results and what not.
Besides efficient view result parsing / object mapping which might be tedious to develop yourself, Ektorp will also help you with view design document management through annotations.
Ektorp has many more features that I think you will appreciate when you dive deeper into CouchDB.
If your app only will perform simple gets of individual documents, then rest template might be enough. Otherwise I don't think you will safe time doing it yourself.
Related
Nowadays typical JAVA application can expose some JPA entities via REST easily. In that case in short there is e.g. persistence.xml where driver, database, etc are defined to access the database and persistence unit easily can be used in the application.
I am looking for something opposite. I.e. if somebody saw the solution where persistence relays on REST API?
Background of my question is the following.
There is an app written in some ancient technology and there is quite complex logic behind. I would like to build new JEE JPA (Eclipselink if possible) based application which could (at least for some time) use that complex logic in order to find and read data. My idea was to implement REST interface on top of old application and let the new one use REST queries in order to deal with the data. Since logic is complex I would like to avoid duplicating it and maintaining 2 branches of code in different technologies until I am fully prepared to move all stuff into modern technology.
Do you think it is possible?
You can design your Data Access Layer and the rest of your new application so that it doesn't care how the data is stored (no "bad" dependencies).
You would then need to create separate versions of the DAL, where one would fetch the data from the legacy REST app and one would use JPA. This will make it possible to start out being dependent on the legacy app, and part by part build the JPA DAL to retrieve data from a database.
I have an existing web forms project which consists of 3 different projects: UI layer (Web project), Business Logic Layer and Database Project. I have already written the data access methods which connect to the database and return data to the business logic layer.
Now we need to provide a REST API, and I was thinking of using oData API along with REST. But all the examples I have seen use Entity Framework and I just cannot use Entity Framework because our data access layer returns data to the business layer, which then processes that data and adds some logic, and then present it to the UI layer.
Can I still use oData API? If yes, then will I need to create fresh methods manually for each of the complex query of oData API? How will OData API access my BL Layer?
You can do this (I have just done similar myself) but it is very hard work.
To me, OData always felt like a way of exposing the entity framework through web services so if you were to try and implement it without the entity framework you will end up spending a lot of time parsing queries to your data access layer.
If you do decide to go down this route, maybe consider only implementing part of the OData spec - work out which parts you actually want to be able to use - as it is huge and the task is daunting.
These are only from my experiences though and you may have a better data access layer API setup than I had when I started which could make things significantly easier.
EDIT to answer last question:
Will you need to create fresh methods manually for each of the complex query of oData API? This will really depend on how your data will be exposed and how your data access layer is setup.
we have a platform composed of few applications.
We have to develop an API which must factorize all interaction to a database.
In this API, we will too have a version of the database in XML format.
The XML format will be used just by one application.
Our application are developped in a classic architectural : dao - service layer - presentation layer.
The DAO layer will be moved into API. No problem on that point.
In many application, the service layer is just a gateway between presentation & dao layer without specific business code.
So my questions are :
should we create the API with a Service layer for each dao ?
if yes, so keep a service layer in application which call service layer from API ?
should we create a service layer in API which manage the factory (database/XML), but that mean each application has to give an information to choose the dao to select (when just one application has this need) ?
or just create all dao in different packages for database & xml in API, keep factory in the application which has the need, and call dao (database) in all others ?
Need help ! :p
I'm lost...
FYI, we are in Java 1.6 with Spring 3.1.1. JDBC Template in DAO for moment.
We are looking informations about spring data jdbc to replace JDBC Template.
Any suggestion about that can be appreciated ^^
[ No Hibernate - JPA solution ]
Thank you.
[edit 1]
In other word, keep a service layer in application & in the API is a way for me to have an abstraction layer. If we have to modify the database structure, maybe we don't have to edit all applications if we can make some changes directly in the service layer of API too.
Imagine 3 possibilities :
service layer in API with factory to choose which dao to use (xml/database)
just dao in API
service layer in API for database & specific layer in API for XML
What solution do you choose ?
[edit 2]
Is it interesting to create an unique class to call the API ? like in a Facade design Pattern.
Use the Service Layer for what is meant to do: provide real world services, by using one ore more DAOs per service offered (and other stuff like managing transactions, sanitizing Strings and other things like that).
If you (together with a more experienced coworker) think you don't need this service layer, then do not put it into your architecture. But make sure to create a proof of concept of your architecture (this may contain the implementation of a somewhat complex functionality of the system or part of it) so you can evaluate it later to demonstrate if you really don't need such layer (or if you do).
My understanding is that you need to decouple and reuse the business layer from the presentation layer, having multiple client applications using the same business implementation.
In this case you need to implement the service layer in the API. Some advantages:
You don't need to repeat the service implementation for any client application handling the presentation.
You can easily decouple the database model design from the business. Design patterns (DTO, Facade) and cross cutting concerns may be easily introduced.
A well designed service layer will require a minimum amount of modifications, compared to DAOs holding DB implementation details.
In this API, we will too have a version of the database in XML format. The XML format will be used just by one application.
By providing this implementation via the API more client applications will be able to use it in the future, if needed.
Spring remoting is offering excellent tools for such a design (RMI, HTTP invoker etc)
I don't see any added value in proving an API for DAOs.
I am developing an app using MVC pattern.
Controllers: servlets
Model: I am following DAO/DTO pattern for accessing database
View: simple JSP EL and JSTL
For accessing database I am using DAO pattern. I want to put validation method and a HashMap for error messages inside the DTO classes for validating FORM data, something similar to Putting validation method and hashmap into DTO.
My question is - this a right approach? If not what is an ideal way for doing this?
As a summary: I want to know real world solutions for server side form validation when we are using DAO/DTO pattern. Please help me.
I believe you need to treat separately the architecture you're implementing and the frameworks you're using to implement the architecture.
Java has a rich set of tools for working on the three standard tiers of your application and choices depend on some factors like expected load and server resources, if you have a two or three users application then it is just a matter of taste.
In terms of DAO/DTO then you have also some options, for example you can build your Data access layer with hibernate and then for your service layer API use DTO's. In this situation you probably want to use a tool for mapping between your domain model and your DTO's (for example jDTO Binder).
Another common approach is to use Spring JDBC Template, there you can go a little bit more crazy and use the same Domain objects as part of the Service layer API.
Finally, the truth is, you can do this by the book or you can do it completely different choice is based on your scenario, taste and experience.
I facing problem of database connection in my project in which i used struts. I cant understand that how i manage my database connections. I want my site good in based on accessing becoz it will get million after launch.
And also face heap size problem in that .
I cant understand that how i will manage my architechture.
Plz guide me,if some one have the knowledge .
I want good java architecture with good management of database connection.
I would suggest you to use Hibernate for DB operation.
It is very good ORM tool
There should be 3 modules atleast for your case of architecture.
1)WebApp
2)Service module
3)Database [Hibernate Module]
Spring has some very good facilities to help you manage DB connections. Have a look at part IV of the documentation : http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/spring-data-tier.html
Spring can help you wether you want to do plain JDBC / SQL or if you want to use a more fancy ORM like Hibernate.
If you want to sustain really high load, that's of course just the begining. You will need a lot of profiling, measuring, tweaking ...
You can look into the layered architecture approach. Struts itself is based upon the MVC architectural pattern.
From Wiki, ...In MVC:
Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made.
Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model.
So, you can comeup with you own data access layer that would work underneath your Model; Checkout A Simple Data Access Layer using Hibernate