Generating DTO, for a clean architecture

[Ryan Barrett]

There was an interesting discussion here a couple of weeks ago regarding implementation of entity-model-binder within MVC, which would load an entity instance directly from IRepository and bind against that.  The consensus was that it was a bad idea, and the discussion kinda stopped there.

I assume that the root problem is this: how do we provide, with minimal effort, CRUD-stlye access to our domain entities?

I've got exactly this problem:  I need to, with minimum effort, give a certain class of users CRUD access to a large number of entities.  This is almost exclusivly during the first phases of a project.  Our customers rarely have the budget (or the ability) to do any serious upfront specification, so we tend to start with an anemic domain model and gradually move towards a proper domain model as the projects grows.

The solution I'm considering is using T4 to generate 'default' DTOs for all domain entities (and value objects).  I already make heavy use of model-level attributes so will move those over to the DTOs.  Then once that's done, make use of similar techniques to generate the repositories and a thin service layer.  All together, we should then be able to generate a simple, disposable application simply from a properly annotated domain model.

Now, I can't see many downsides, so my question:  am I missing something?  Is my idea a good one, or is it dumb?

-- 
Ryan

[geoffrey smith]

I believe the T4 templates are exactly what you're looking for. Of course, I'd like to gently remind you that one of the things that Code Complete hits you over the head with is that your clients can't afford not to do more detailed specs up front.

Where templates really fail is when the objects have more complex relations to each other, at least from a human perspective. I believe I've talked about this before, and I've seen no good solution, but what happens when your simple CRUD requires a user to pick a cost code out of a couple thousand? A drop-down won't work here, which means you'll need them to provide you input. Either through searching, and then picking one out of a search, or simply letting them enter their own cost code (say "04-300") and have a RegEx or method parse the string to get the correct cost code, verify it against the db, etc.

--
You received this message because you are subscribed to the Google Groups "S#arp Architecture" group.
To post to this group, send email to sharp-arc...@googlegroups.com.
To unsubscribe from this group, send email to sharp-architect...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sharp-architecture?hl=en.

[Ryan Barrett]

I agree 100% about detailed specifications.  It's just something that my (current) employers don't believe in..  That's something you see often in Microsoft houses, especially those who've had a strong past in Visual Basic.  Software engineering's often lower down the list of priorities than producing quick results is.  That's fine for small, in house projects, but falls apart quickly if you try to scale (in complexity or reach).

My personal opinion (and experience) is that rapid prototyping is extremely effective when applied during the specification phase, as long as the code created is cheap.  Think of an effort similar to that of putting the concept into the form of a functional/technical specification.

You can cover a lot of 'dropdown' cases by putting the idea of a selectable entity into an interface and implementing that on entities.  I'm thinking of doing something similar for filters when there's a master-detail relationship.  I'd argue that if your domain involves such relationships, then it's not at all crazy to build infrastructure to cover 80%+ of the cases where it occurs.

For selecting a single code out of 1000, I've found auto-complete combined with a 'searchable' string property (which is unique for the entity) to be really effective.

I should add that, so far, I've always implemented these things by hand.

For the record, I'd be interested in seeing how this problem has been approached in the Naked Objects framework.  They must have hit this problem, and must have solved it...  

-- 
Ryan

[geoffrey smith]

I don't know about the Naked Objects framework, but Grails does this sort of scaffolding really well:

https://github.com/grails/grails-core/tree/master/src/grails/templates/scaffolding

and here:

http://www.jakusys.de/blog/2008/12/grails-scaffolding-in-depth/

Unfortunately, rapid prototyping isn't something Sharp does very well at this point.