I've been reading all the CSLA books and modeling behavior (while still hard for me to change my thinking) seems like a great way to solve a bunch of problems.
But if, as Rocky put it, the likelihood that the relational model looks like the object model is very small, then how is it possible to build templates that start with the object and build a DAL with any accuracy?
I was going to put together a small database to feed my templates and use the templates to generate the code for a lot of the standard stuff, but if I'm modeling behavior, then the DAL structure won't match.
Does everyone just generate the DAL by hand?
I look at it this way (based on my experience over the years).
Most apps I've worked on have a lot of maintenance screens, a few moderately complex screens, and a small number of very complex screens.
Conversely, users spend most of their time using the very complex screens, some time in the moderate screens, and little time in the maintenance screens.
What is interesting is that the maintenance screens are often nearly 1:1 with database tables. So I'm all for using a data-centric code generation tool to create the DAL, business objects, and screens for the maintenance screens.
You might be able to use some code generation for the moderately complex screens, depending on specifics.
As a result of using code generation for the simpler screens (the majority of your screens btw), you should free up more time to spend on doing a really excellent job manually crafting everything necessary to support the complex screens.
This is wonderful, because it means you'll put the greatest energy and focus into the part of the app the users really care about and use most. As a result, your users should get an experience better than they'd normally expect, because you didn't have to waste a lot of time building the boring screens.
Thanks for the quick reply (and sorry for my slow response).
That's where I started, then realized that my objects were getting shapes like your Project -> Assignment, one to many tables but that your object was a "ProjectEdit" object.
All of a sudden I was looking at even my basic CRUD maintenance screens each with an "-Edit" behavior orientation (since they were doing something) and got confused.
I guess as tempting as it is to lump multiple behaviors into a single object, that's where the trouble starts.
So it seems, as always, it's a blend of approaches.
Thanks for the insight.
Copyright (c) Marimer LLC