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.

Apache Isis Proposal

Over the last few months we’ve been seriously considering donating both the original Naked Objects framework as well as my sister projects to the Apache Software Foundation, sounding out various people and gauging interest. Today we formally announced a proposal for a new project to be accepted into the Apache incubator. The name we’re proposing for this combined project is Apache Isis.

The rationale is to develop Isis into a standards-based framework for building domain-driven apps, appealing both to its user community (who just want to use it “out-of-the-box”) and to its contributor community (who want to quickly understand how it works and what is required to extend it). Ultimately it’s about securing the future of the framework to allow more people to realize the benefits of domain-driven applications when developed using the naked objects pattern.

You can read the full proposal at: http://wiki.apache.org/incubator/IsisProposal. If you like what you see, then why not get involved. And if you don’t, tell us why so we can address it.

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon

Simulating CDI’s Session and Request Scope in a J2SE app

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

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon

sp__crudparams for CRUD-style stored procs in Sybase ASE

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

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon

Naked Objects MVC is released!

In my book I focus on the open source Java version of Naked Objects, but (as I briefly mention) there is also a commercial version of Naked Objects that runs on .NET. This is developed by Richard Pawson’s company, Richard being the originator of the Naked Objects pattern; (Richard and I continue to work closely together over in Ireland, but that’s a different story).

Anyway… Richard and his team have been working on a new web-based viewer for Naked Objects.NET, running on top of ASP.NET MVC. Naturally enough, he’s called it Naked Objects MVC.

Like my own Wicket Objects viewer, Naked Objects MVC provides a full webapp from just a domain object model, but then allows the GUI to be customized in a variety of ways.

So, if you’re a .NET developer, do check it out. Richard’s put together some videos on his website so you can quickly assess if it’s for you:

  • Creating a new application
    New MVC App
  • Understanding how the UI relates to the domain model (no surprises here if you’ve read my book)
    Exploring Naked Objects MVC
  • Customization
    MVC Customise

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon

Wicket Objects v0.1 … give it a try

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:
wicketobjects-blog-screenshot

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:
wicketobjects google maps mashup

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?

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon

Pojo Properties Auto Testing

Doing another run of my TDD course, and one of the attendees raised an interesting question: are there any tools to automatically test pojo getters and setters? We couldn’t find any, and it sounded like a challenge worth tackling.
Continue reading Pojo Properties Auto Testing

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon

Groovy Objects, baby!

I was at the SPA conference last week, ostensibly to do a little talk on Naked Objects, but mostly to mix and talk with some cleverer people than me to pick up some new ideas.

In a break I was asked whether Naked Objects supported Groovy. To which my answer was: “well, no, but it’s been on our list to look into ages, and it really oughtn’t be hard if we ever got round to it”.

Anyway, so I’ve got around to it, meaning there’s now a new sister project that’ll let you write your domain objects in Groovy, to run on Naked Objects. Continue reading Groovy Objects, baby!

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon

Project Ideas, Viewer Stories and Wicket

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.

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Reddit Post to StumbleUpon