Not specifically about a DAO but an Architectural approach that I am
using and works well
for me is the following:
1. I have an Application POJO that models my Application/System.
The methods it exposes are what the application can do.
For example:
Application app ....
app.addCustomer(customer);
2. The Interfaces to the Application are separate and essentially
marshal requests
and responses to and from the Application.
Example interfaces are: Command Line and REST
3. REST access to the Application is provided by Dropwizard (which is
excellent).
This Interface marshals documents (in JSON/+links) between the
client and the server which
result in interactions with the Application (POJO).
For example, when a POST is made with JSON containing new customer
details this Dropwizard layer marshals the JSON into a Customer
object and then
calls the Application.addCustomer() method.
The REST layer is responsible for providing a discoverable and
navigate-able document
structure that represents an allowable interaction state with the
Application.
4. This loose coupling / separation / anti-corruption layer means that
the concerns of interfacing
with the Application are not part of the Application. This enables
the addition of new Interfaces
more easily.
For example, a message queue could be added to marshal request/
response objects to and from
the Application without changing the Application POJO or domain
objects underneath it.
In coming full circle back to the Controller/DAO question, I have
domain objects within my Application
POJO that control facets of the application. You might call these
Controllers. I don't.
The Domain objects have Repository objects that represent a Store
(persistent or otherwise).
- James.
On Aug 2, 4:24 am, Fredrik Hörte <
fredrikho...@gmail.com> wrote:
> Thanks Adam,
>
> and then I guess you are passing in your DAO in your Controller when
> initializing it?
>
> Something like this?
>
> environment.addResource(new Resource(new Controller(new DAO()))
>
>
>
>
>
>
>
> On Tuesday, July 31, 2012 10:09:34 PM UTC+2, Adam Kaplan wrote:
>
> > This seems to be more of a Jersey question than a Dropwizard question.
> > What you can do is pass the FooBarController (or your 'environment' if
> > you're using DI) to the Resource constructor.
>
> > Here is some overly simplified example code in which I pass a controller
> > to a resource during initialization. It's in Scala, but straightforward.
>
> > Service:
> > override def onInitialize(configuration: ServiceConfiguration,
> > environment: Environment) {
> > environment.addResource(new Resource(controller)
> > ...
> > }
>
> > Resource:
> > @Path("/")
> > @Produces(Array(MediaType.APPLICATION_JSON))
> > protected class Resource(val registry:Controller) {
> > ....
> > }
>
> > On Tuesday, July 31, 2012 1:41:51 PM UTC-4, Fredrik Hörte wrote:
>
> >> Hi,
>
> >> I just started with dropwizard (*awesome btw*) from Spring and I wonder