Domain-driven design (DDD) focuses on what matters in enterprise applications: the core business domain. And Naked Objects lets you build DDD applications just by writing the core domain classes, the rest of the application is taken care of for you.
This blog supplements and expands on my book, Domain Driven Design using Naked Objects, describing how you can rapidly develop and test domain applications using Naked Objects.
|
We’re currently considering refactoring the Naked Objects framework to use JSR-330 (dependency injection) and EE-oriented big brother, JSR-299 (CDI). Using vanilla JSR-330 is a no-brainer, but there are also some nice features in JSR-299 that we’d like to exploit (such as events and decorators). The snag? The Naked Objects must also run transparently in J2SE environments.
Now JSR-299 (at least, the Weld reference implementation) can run on J2SE, but it isn’t possible to use beans that are annotated as either @SessionScoped or @RequestScoped… not surprising really, because there is no HttpSession or HttpServletRequest to hook into. On the other hand, at least in the Naked Objects framework in a J2SE context, we do have the ability to map these concepts onto its own internal lifecycle … eg, for a client-side app, the user is always in deemed to be running in one long session.
How, then, to setup contexts for these scopes, and make them automatically active when running in J2SE? Continue reading Simulating CDI’s Session and Request Scope in a J2SE app
      
Slight diversion from the norm…
Suppose you want to write a CRUD-style sproc, for Sybase ASE. If we were writing for Oracle, we could just use its %ROWTYPE syntax. But Sybase doesn’t have anything equivalent. Instead, we’ll need to have a set of params matching the columns of a table.
The following stored proc, sp__crudparams, will generate an SQL fragment that you can then copy and paste into your editor. Here’s how it works for the pubs2..titles table:
exec sp__crudparams titles
go
--------------------------------------------------
@pub_id char(4) = NULL
,@type char(12) = NULL
,@title varchar(80) = NULL
,@notes varchar(200) = NULL
,@total_sales int = NULL
,@price money = NULL
,@advance money = NULL
,@pubdate datetime = NULL
,@contract bit = NULL
,@title_id tid = NULL -- varchar
And here’s the stored proc itself: Continue reading sp__crudparams for CRUD-style stored procs in Sybase ASE
Over the last few months I’ve been plugging away at another sister project for Naked Objects, this time a new web-based viewer built using the Apache Wicket web framework. I reckon it’s now in a fit enough state to be tried out more widely, and hopefully find some contributors with better web UI skills than I do!
But what does it do? Well, Wicket Objects is a way of rapidly developing web apps simply by writing the domain objects. Fundamentally it consists of a set of Wicket IModel’s that wrap the NO metamodel, and a bunch of Wicket Components that can render those IModel’s. Given that there’s no UI code to write to get a fully-functional webapp, this means you can develop good code, very quickly. Then, when you do need to start to customize the app, you can just use the Wicket API against the aforementioned IModel’s.
Here’s a screenshot of Wicket Objects in action with its standard form for an entity:
I’ve put together a new Maven website, plus some docs, and I’ve uploaded a snapshot into the sister projects snapshot repo. So, to try it out with a small test app, just do the following:
svn co https://wicketobjects.svn.sourceforge.net/svnroot/wicketobjects/trunk/testapp/claims .
mvn clean install
cd webapp
mvn jetty:run
To logon, use sven/pass.
One of the objectives of Wicket Objects is to be customizable. But I didn’t want to invent some new proprietary API for developers to have to understand. Hence choosing Wicket; I basically use its API for building Components as my customization API.
That also makes it easy to reuse 3rd party Wicket components to create customized views. For example, we can customize Wicket Objects so that Locatable objects are displayed in a google maps mashup; behind the scenes this uses the gmap2 Component on WicketStuff:
So, please give it a try. And if you like what you see and either already know or want to learn Wicket, why not help me take it up to a 1.0 release?
You might (but then again might not) have noticed a couple of new (permanent) pages at the top of this blog.
- The first lists a number of project ideas for extending Naked Objects, of various sizes. As well as being indicative of the flexibility of the NO framework, I’m also hoping that they’ll inspire anyone looking for an interesting project to work with. In particular, if you’re a IT/CompSci student looking for a subject for your thesis, then check them out.
- Second, and related, I’ve also put up a page that lists a set of user stories / features that make up a reasonably comprehensive viewer for Naked Objects. Naked Objects itself already as the DnD viewer and the HTML viewer, and the next version will include the Scimpi web viewer too. Meanwhile in the sister projects my Restful Objects is a viewer of sorts, and I’ve been working on a new one based on Wicket (more below). Anyway, take a look-see; if you fancy writing a viewer in Android or JavaFX, it’ll give an indication of the work required.
And finally, onto Wicket. I was able to rattle off that list of stories because I’ve spent my last couple of months of spare time and odd days working on a generic OOUI viewer based on Apache Wicket. This basically picks up on the stuff I covered in chapter 15 in my book where I demonstrate the principle.
Anyway, so we now have a new sister project, called (you can probably guess) Wicket Objects. It’s not quite finished but is getting pretty close, and I’m gonna be demonstrating it at the SPA conference in London in a week or two. I have to say that I love how this little project has turned out: Wicket Objects leverages Wicket for the UI, has Naked Objects do the back-end stuff. As a developer you get a Wicket-based UI for your domain objects for free, which you can then extend using your Wicket knowledge as need be.
I’m gonna be blogging more about Wicket Objects as I tidy it up and get its documentation together; in the meantime there’s some basic notes on its wiki at Sourceforge.
|
|
