incubator-photark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luciano Resende <luckbr1...@gmail.com>
Subject Re: Running the filesystem instead of jcr
Date Tue, 08 Jun 2010 02:15:58 GMT
On Sun, Jun 6, 2010 at 8:22 AM, Avdhesh Yadav <avd@avdheshyadav.com> wrote:
> Yes I think Facade layer is good idea and i am planning to work on this.We
> can not simply flip to other implementation from the web.composite.Facade
> layer helps in switching between different providers.
>
> Right now we have two different types of dataproviders .. JCR based and
> DataStore(for google apps Engine  JPA/JDO..Not Implemented Yet).
>
> Here is code snippet.
> -----------------------------------------
>
> // This class go in Photark Module
> interface DataProvider
> {
>       public AlbumRepository  getAlbumRepository();
>
>       public UserRepository getUserRepository();
> }
>
>
> //JCR Based Implementation
> // Photark JCR module
> public class JCRDataProvider implements DataProvider
> {
>       private JCRRepositoryManager repositoryManager;
>
>       public JCRDataProvider(JCRRepositoryManager repositoryManager)
>       {
>           this.repositoryManager = repositorymanger
>      }
>
>       public AlbumRepository  getAlbumRepository()
>       {
>         AlbumRepository albumRepositry = new
> JCRALbumReposiroty(repositoryManager);
>         return albumRepositry;
>       }
> }
>
> //DataStore Based Implementation
> // PhotaArk FileSystem module.
> public class DataStoreProvider implements DataProvider
> {
>       private JDOPersistence jdoPersistenceManager;
>
>       public JCRDataProvider(JCRRepositoryManager jdoPersistenceManager)
>       {
>           this.repositoryManager = repositorymanger
>      }
>
>       public AlbumRepository  getAlbumRepository()
>       {
>         AlbumRepository albumRepositry = new
> JDOALbumReposiroty(jdoPersistenceManager);
>         return albumRepositry;
>       }
> }
>
> //Photark Module
> public interface AlbumRepository
> {
>
> public String findCoverImage(String albumName) ;
>
> public String addAlbum(String album);
>
> ...................
>
> }
>
>
> // Photark JCR Module
> public class JCRAlbumRepository implements AlbumRepository
> {
>      private JCRRepositoryManager repositoryManager;
>
>      public String findCoverImage(String albumName)
>      {
>          // use the repository manager and fetch the data from the
> repository
>
>      }
> }
>
>
>
> similary we have seprate implementation from DataStore Based
> // Photark FileSystem Module
> public class DataStoreAlbumRepository implements AlbumRepository
> {
>      private JDORepositoryManager repositoryManager;
>
>      public String findCoverImage(String albumName)
>      {
>          // use the repository manager and fetch the data from the
> repository
>
>      }
> }
>
> This way we separate the Data Access from the Model objects and Services.
>
> This API also helpful in developing the Security Module.In security module
> we need to fetch the data for users and also save the permissions,
> etc.Security module should not be dependent on the Implementation other we
> can not deploy it on the google apps engine.The propose facade layer help in
> achieving this by injecting the  the interface DataProvider instead of
> concreate implementation and i would work with both Google apps engine and
> Tomcat.
>
> If all are agree on this I would like to work on this
>
> Thought/Suggestions welcome
>


Are you trying to follow the DAO pattern within our API ? If so, I
think this was the original intent when we defined the Gallery facade.
In this approach, what is going to be the responsibility of
Gallery/Album or other services, other then simple delegation to the
proper dataStoreProvider ?

Also, I have a feeling you are proposing this because of the comment I
added to the OpenID JIRA mentioning that the security module should
not have dependency on JCR module.

So here is the general Design Principles I usually have in mind :

Define business objects/domain models (e.g album, image, user, etc)
Define service interfaces/facades that act on these business objects
(e.g UserAuthentication, Gallery, etc)

These two types of artifacts should be defined in a module that is
free of implementation specific 3rd party dependencies (e.g our
photark module or security module)

In this approach, at least to our current extent, the Service Facades
becomes the actual DAO, which then have different implementations such
as JCR based Gallery versus FileSystem based gallery. The application
then uses SCA assembly (composite file) to wire the specific
implementation of these services.

The current issue is that we sometimes cross the boundaries of the
service interfaces, accessing the repository directly, making things
more complex and sometimes less prone to reuse, and then comes the
necessity of a new layer of abstraction... which is why I'm trying to
promote a clean layer with specific contracts and dependencies on
other services in the rest branch.


-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Mime
View raw message