Mb-devel email

Hi again,

I want to resurrect this again, with some slightly more concrete
thoughts on these changes, as I feel these are becoming more and
more important as we start to consider NGS. First, changes to the
work I've done myself:

--

There is a strange dependancy (that I somehow thought was a good
idea) between controllers and forms. The logic to update models is
being delegated to forms, when it should be happening in the actual
controllers. Furthermore, I'm going to change forms so that they
are only interested in validation, and transforming from posted
data to objects (ie, date strings get transformed into DateTime
objects).

Reason for this is I think it's going to make returning to code a
lot simpler in the future. It's less indirection, and doesn't really
make sense to be split as it is at the moment.

--

Next, I'm going to remove all my code from MusicBrainz::Server::Model
- again, there's an overlap of functionality - this functionality
belongs in just the MusicBrainz::Server::Artist objects. The Model
namespace will remain, but I'll be using a very simple Catalyst
class (we're talking just a few lines, see Catalyst::Model::DBIc::Schema
for an example) just to bind the models to Catalyst (which is exactly
how Catalyst should be used).

--

With these changes in place, I'd like to then start work on a new
architecture. As mentioned before, this involves splitting the row
objects from the database methods themselves. While I'm happy,
personally, with an ORM type API - with the relationships between
rows at the object level, I will move these the database packages
if people feel this is better.

It's mostly a difference between:

    my $artist = MusicBrainz::Server::Artist->load(id => $foo);
    my $releases = $artist->releases(
        attributes => [ MusicBrainz::Server::Release::OFFICIAL ]
    );    (1)

and:

    my $artist = MusicBrainz::Server::Artist->load($dbh, id => $foo);
    my $releases = MusicBrainz::Server::Release->search(
	$dbh, artist => $artist, attributes => [
	MusicBrainz::Server::Release::OFFICIAL ]
    );    (2)

Personally, I find (1) a cleaner solution, but I understand some
have preference for the latter (hopefully I've captured the idea
correctly).

--

With a sensible architecture like this, I'd like to move some of
our logic out of the MusicBrainz::Server namespace, and rely on
some other packages in CPAN to do this for us. Some examples include
Params::Validate for parameter validation (or possibly
MooseX::Params::Validate - basically the same), and making more use
of Moose where it makes sense.

I know some people are skeptical about Moose, but the final point
that's made me settle about it is a) the team behind it and b) it's
being adopted for Catalyst, and soon DBIx::Class - some of the
biggest and most frequently used Perl packages in web development.

Moose would allow us to do things like horizontal code re-use,
through roles, some more validation (type system) so we can be
certain about the data we are working with, and it's a seriously
rock-solid object API.

But this is probably the last matter, and will likely need more
discussion when we get to it...

--

This covers most of the main things I can think of. I'd *really*
like to hear what people have to say about this - I feel quite
strongly about code architecture, and really want to get it right!
And most likely, I *don't* know best :D

Please let me know what you think!
- Ollie