If your orm tool wants to generate from tables, it doesn't mean you have to generate from the tables your application will use, right? So just build some tables (perhaps in a throw-away database unless you'll use them later for re-generation) that have fields that manfest the properties you want your Class to have and write DataPortal code that knows which are the real tables in which the data is persisted whether it's in one or a family of them.
That might require that your generated class file doesn't provide the data portal methods. But it still gets you well down the road to automating the really boring code. And with the power of stored procedures in SQL2K5, you can probably even generate the code for those DP methods by just calling a sProc with a standard class-based name and arguments. Just put the target-table-awareness in the sProc rather than in the DP code.
I always think of this as another wrinkle on the idea of making lemonade if your situation gives you lemons. It isn't really so incovenient, is it?
JonM:
In fact many of the troubles I had early on were caused because my objects mirrored my db and it wasn't a very pleasant way to interact with. Sure I can understand it because I built the db, but end-users don't need/want that kind of transparency. Now many of the simple configuration and setup screens worked fine with classes that mirrored the db model. It seems to fall apart with more complicated objects. Does anyone have a good answer for this?
What you are finding here is what David Taylor calls the impedance mismatch problem. This problem exists because a well-designed object model doesn't look like a well-designed relational model.
ORM tools largely focus on projecting relational data into a set of objects that are also effectively relational. And that's very cool and powerful and useful! Unfortunately that doesn't address the impedance mismatch problem, it just shifts it from a db<->object issue to an object<->object issue.
On the upside, the object<->object issue is much easier to address, because we have a richer set of tools (like reflection, etc) to deal with objects than we do with databases.
I agree with Brian, using DTOs as a contract between your business objects and the data layer is a good solution. It is slower than using raw ADO.NET like I do in the book, but it is more flexible and abstract.
Consider that web services, WCF services, LINQ (in all its forms) and many ORM tools all return DTOs (or "entity objects", which are usually just glorified DTOs). So if you have a good way of mapping DTOs into your business objects then you have pretty broad coverage of the data access world.
This will be my focus with CSLA 3.5: make it as easy as possible to work with DTOs as a "data source", thus enabling LINQ, ADO.NET EF, web services and WCF services all in one fell swoop.
(though I won't do anything to block direct use of ADO.NET - sometimes performance is still priority number one after all)
Copyright (c) Marimer LLC