Andrus,
What you describes is very similar to the pet-store example, and also
seems very reasonable to me.
I guess my only problem now is to learn a bit more about
ObjectContext. I don't really know what I need there, since I don't
really understand what an ObjectContext represents. In the past, for
web applications like the one I am planning now, I have used a DBCP or
similar to get java.sql.Connections that are later used by objects to
perform queries. Of course, this is pretty tedious, and thus why I am
looking at Cayenne.
The documentation suggests that for web applications one DataContext
tied to each user session (say, via a filter) is appropriate. Why do I
need more than one DataContext in my application at all? I could just
create a singleton that gets DataContext to any object (DAO) that
needs it. What is the drawback there?
What about unit testing? How do I provide a DataContext to my tests?
I guess I just need to understand what a DataContext (or ObjectContext
for that matter) is all about.
Thanks for the help,
-- Ylan.On Apr 21, 2009, at 6:43 AM, Andrus Adamchik wrote:
> Yeah, it depends greatly on the general app architecture and usage > patterns... IIRC the petstore example was taken from Spring and > rewritten with Cayenne, so it may have some of the Spring-induced > artifacts (don't remember all the details). > > The pattern I am personally following lately in the systems that > have an IoC container (say Spring or Tapestry), is to define one > generic Cayenne "service" that gives access to an ObjectContext > depending on your needs, and a bunch of "DAO services" that > encapsulate specific queries and other data operations, including > cache strategies. This way the frontend code doesn't have to deal > with cache rules and other low level details. This requires some > thought on the design, but at the end scales best in terms of > complexity. > > Here is some examples: > > interface CayenneService { > // depending on implementation this can return application or > session-level shared context. > // often this is a read-only context... > ObjectContext getSharedContext(); > > // creates a new context > ObjectContext createNewContext(); > } > > interface AccountDAO { > > List<Account> getActiveAccounts(); > > List<Account> getNewAccounts(); > > List<Account> searchAccounts(Stirng searchCriteria); > } > > > class AccountDAOImpl implements AccountDAO { > > // injected > CayenneService cayenneService; > > List<Account> getActiveAccounts() { > SelectQuery query = new SelectQuery(Account.class); > query.andQualifier(...); > query.andQualifier(...); > > query.setCacheStrategy(...); > query.setCacheGroups(...); > > return cayenneSerice. getSharedContext().performQuery(query); > } > } > > Andrus > > On Apr 21, 2009, at 4:26 PM, Michael Gentry wrote: >> I'm not familiar with the Pet Store example, so I'm not sure what was >> meant by it not being a best practices example. Also, people have >> many different ideas of what they think a best practice is, so it can >> vary greatly. >> >> My typical usage is to put my custom business logic in the >> Cayenne-generated subclass and to also put my "fetch" type methods in >> there, too (when not creating them in Cayenne Modeler). The more >> interesting questions (to me) are what are the usage patterns, etc. >> That helps determine how to use the DataContext (or ObjectContext), >> how to do data refreshing, etc. One application I did had a single >> read-mostly DC that I synchronized access to for all the users (the >> queries took a prohibitive amount of time for interactive usage, so I >> cached things in a single DC). Others I used one (or more) DCs per >> user's session. Again, it really depends upon what your requirements >> are for data access. >> >> Feel free to ask more questions. Hope that helped just a little. >> >> mrg >> >> >> On Mon, Apr 20, 2009 at 3:30 PM, Ylan Segal <ylan.sega..mail.com> >> wrote: >>> Hi Everyone, >>> >>> I am new to Cayenne. I was looking at the examples in the wiki, >>> especially >>> at the pet store: >>> >>> http://cwiki.apache.org/CAY/cayenne-petstore.html >>> >>> So far, I like what I see. The above page does mention that the >>> pet store >>> example "... definitely needs a rewrite and DB redesign before we >>> can call >>> it Cayenne Best Practices Demo." >>> >>> Why isn't it a best practice? Because of the DB design or because >>> of how >>> Cayenne classes are used? The overall app design (one domain >>> package, one >>> DAO package, one presentation package) seems reasonable to me. I >>> would be >>> designing a DB schema from scratch for a web application (probably >>> with >>> struts), and I am thinking of following the example pattern, >>> assuming that >>> pattern is not what needs rewriting! Can anyone suggest best >>> practices for >>> this type of situation? I am looking for more of a "what packages >>> should we >>> have" discussion rather than a "this is how you save an object to >>> the >>> database" discussion. >>> >>> I hope this makes sense. >>> >>> -- >>> Ylan Segal >>> ylan.sega..mail.com >>> >>> >> >
This archive was generated by hypermail 2.0.0 : Tue Apr 21 2009 - 14:37:37 EDT