Article: New Extensions Rev Up Stripes MVC

Discussions

News: Article: New Extensions Rev Up Stripes MVC

  1. Article: New Extensions Rev Up Stripes MVC (6 messages)

    Stripernate, a light-weight Java library developed by Aaron Porter, is the answer to Rick Smith's Stripes persistence dreams. In this article, Smith describes all things Stripernate, from EJB3 tricks to security. Stripernate binds Stripes with Hibernate's EJB3 implementation. Domain objects in your Stripes project are automatically identified and injected into the Hibernate layer upon application startup. Stripernate also rolls forward Hibernate validation errors to your Stripes layer so they can be displayed to the user. What are your thoughts on Stripernate?
  2. Good for a simple web-based database front-end, but I'm not sure how well this would work for an application with more complicated business logic and processes that need to co-ordinate transactions across multiple domain objects. In other words, Stripenate eliminates the service layer of your application, which is not needed for CRUD-based apps, but I think is needed for more complex interactions with the data.
  3. Hi Paul,
    In other words, Stripenate eliminates the service layer of your application, which is not needed for CRUD-based apps, but I think is needed for more complex interactions with the data.
    I would say Stripernate eliminates the NEED for a service layer in your application for CRUD-based activities. There's nothing in the framework I can see that would preclude you from using Stripernate along with a service layer if you needed one.
  4. I would say Stripernate eliminates the NEED for a service layer in your application for CRUD-based activities. There's nothing in the framework I can see that would preclude you from using Stripernate along with a service layer if you needed one.
    Stripernate definitely doesn't eliminate the need for service and DAO layers. Creating a hibernate session in the ActionBean and querying it directly might work for simple apps, but I would discourage this for more complex apps. You will end up with a lot of code in the action bean and probably duplicated code. For example, in your example you have this code in your Employee action bean:
    public List getEmployees() { List employees = getSession().createQuery( "from Employee order by lastName asc").list(); return employees; }
    Now let's say as your app grows, you end up needing to get the list of all employees in several different aciton beans. Then, someone tells you that you need to keep track of which employees are active, and not show inactive employees on the site. Now you've got to go find all the action beans that have this code in it and add "where active = 1", or something like it. If you had all of your action beans accessing a service or DAO layer method, your could make that change in one place. BTW - I wouldn't recommend calling your action bean "Employee" and your model "Employee". First off all, the stripes convention is to call your action beans "EmployeeActionBean", I don't see any reason to break with that, unless that is convention with Stripernate? Also, you can see how your have to fully qualify the Employee model bean when you reference it in the action bean. That wouldn't be necessary if your called your action bean "EmployeeActionBean". Paul Barry
  5. Hey Paul, Thanks for your comments.
    First off all, the stripes convention is to call your action beans "EmployeeActionBean", I don't see any reason to break with that, unless that is convention with Stripernate? Also, you can see how your have to fully qualify the Employee model bean when you reference it in the action bean. That wouldn't be necessary if your called your action bean "EmployeeActionBean".
    I am not sure there's a single Stripes convention for naming an actionbean. If you'll check out the Stripes defaults page, you'll see that the url binding model is set up to handle a number of different names for the ActionBean classes. My intent for the demo app was to try to keep things as simple as possible and show a relationship between the domain model objects and the ActionBeans that handled them. I concede its a little more verbose and I'll take your advise in my future demo apps. Regarding your first point about service layers, I think that smarter persistence engines like Hibernate have taken care of some activities, like updates to joined tables, for example, that may have been handled previously in the service layer. (At least that's how I did things with Ibatis) Also I've found that Stripes' ability to bind multiple actionbeans to a jsp provides a functionality that is similar to what your are referring to in a service layer, that is, it allows me to consolidate alot of data actions in a single actionbean and use them anywhere.
  6. Hi Paul,
    Stripernate definitely doesn't eliminate the need for service and DAO layers.
    DAOs, yes... but more or less with finders only. Of course, having HQL in the UI tier is not a good idea (what about layered architectures ?). But having behavior outside of the objects isn't better if you think about it (what about encapsulation ?) ! Domain Objects should encapsulate behavior. You shouldn't have to put this in services (everybody tends to do this because it's simpler to manage, but it gets you down to procedural languages or almost !). Stripernate, in the same mood than Naked Objects or JMatter, enforces clean Object Model design, precisely because it makes the hb session etc. almost transparent.
    Creating a hibernate session in the ActionBean and querying it directly might work for simple apps, but I would discourage this for more complex apps. You will end up with a lot of code in the action bean and probably duplicated code.
    Once again, no services doesn't mean that you have to put biz stuff in the UI tier ! Let's take a simple example : a cart checkout. The SOA way : CartValueObject cartVo = ... ; CartService cs = ... ; cs.checkoutCart(cartVo); The OO way : Cart c = ... ; c.checkout(); Of course, you'd still need a DAO, just to do things like : cartDao.loadAll(); cartDao.load(id); ... But you clearly don't need to write service facades, DTOs and the like... At least not for developing a Stripernate webapp. A few finders (e.g. in helper classes, call them DAOs, managers etc.), well designed classes, and you're done ! My €0.02 Remi
  7. Kudos ![ Go to top ]

    Hi there, Nice article, good to see this here ! Stripernate definitly rocks, and there's definitly been interesting moves around Stripes these times. To add credit to it if it needs it, I've been converting colleagues at work last week, used to PHP, .NET and other crap... the feedback was awesome ! Actually, most of those guys were able to code a full-stack java webapp in 2 days ! They were amazed by how easy it is to write real 00 apps easily, without the usual plubming issues ! It's really worth a look for people willing to switch to Java but are scared about the config and design headaches... You don't need to be a tough programmer to get your dreams come to reality with Stripernate... write nice Objects, annotate them, and get them browser-enabled in a few minutes :-) Last but not least, it enforces natural and clean design IMHO : you simply write Objects with Stripernate, you don't really have to care about the whole Services/DAO stuff... As Rick says, it may eliminate the need for services (after all objects should encapsulate behavior, so what's the point in services if you think about it ?) Maybe the most appealing entry level framework out there IMHO, just simple but powerful (and I don't talk about the high quality docs and support, bug fixes etc.) ! Kudos to the Stripes folks, and thanks for all ! Keep up the vibe ! Cheers Remi