Brendan Tompkins [MVP]

Here is a good resource to get you started:

http://www.xml.org/xml/registry_searchresults.jsp

Have you looked into using a code generation tool like CodeSmith?

http://www.ericjsmith.net/codesmith/

Eric.. Yes. I've heard lots of good things so far and have a copy of the demo...

Definitely will be a part of my entity framework solution. Right now, I'm hand coding my stuff so I have a good handle on what needs to be generated.. Currently wallowing in ITypedList implementation to do complex databinding.. uggh.

Nice idea.

There is a book like this for Data modeling called the data Model resource handbook. In OO though, you might have to make distinction between boiler plate entities for Analysis models vs those for design models, but all in all an excellent Idea. I'd love to contribute.

Hi Brendan,

I'm pretty sure that you will find this book worth a look:
"Enterprise Patterns and MDA. Building Better Software with Archetype Patterns and UML" by Jim Arlow and Ila Neustadt.

Best Regards,
Jimmy
www.jnsk.se/weblog/
###

Benjy, Jimmy.. Thanks for the pointers, I'll definitely look into these books. I'm still wondering if something like this would be useful. On the one hand, it'd be nice to have boilerplates for stuff like contact info, addresses, orgs, currency, etc. On the other hand this stuff is pretty easy to come up with yourself, and most of the hard work goes into domain-specific modeling.

What would be nice to have done for you would be base classes that handle the overidden equality methods and collections.

I'll give you a for example of something that's been bugging me: What's the best way to structure an address class? Does it have a sub-city state zip obejct? A sub country object? Should it be flat?

-Brendan

Brendan,
Awfully sorry about the late reply to your post. I havent had much time to browse recently.Been stuck in a very hectic project.

I think reference models are always a good idea cos people can look them up and find things that they might have missed. They dont have to be copied and implemented in projects AS-IS. They can be accompanied with notes indicating where designs differ, such as the case you have pointed out and people can make up their minds about which way they want to go. So all we really need to setup is a set of pages with sketches and notes and take it from there.

In reply to the Address thing, I would say that it depends on the scope of the component. A highly generalized component would need the sub-object because you could then put in a RegEx based validation in the class that could handle validations based on whether it is a US address or a European address etc. But if you are building a completely local system that wont be used across the world, then you could settle for a fully flat structure which would be easier to handle and probably much faster too.

I had a discussion regarding Financial domain objects with a colleague sometime ago and we looked at scenarios such as Social Security Numbers or NI numbers (in UK) , Employee Ref Numbers etc and we had two options

(a) Either create a generalised entity called ReferenceData and have a IClassifier type interface on it so we can store all types of references or
(b) just create an EmployeeMiscInfo object and store it all which was easier for the small scope of the project we were looking at .

Hope this helps.

Benjy

Thanks Benjy! Interesting stuff.