Hank,


Have you seen this http://channel9.msdn.com/pdc2008/TL16/ ? Start with minute 58 - The evolution of C# - and a bit later - the Compiler as a Service


Won't that be useful for metadata ?

The overhead will be minimal imo - it's just compiling from C# to ild


>Hi Greg,
>
>no -- I have all the mapping done before I even think about creating the database <s>. It's this one: http://aapl.codeplex.com/
>
>This is his example of code:
>
>

>public BlogPost GetBlogPost(Guid postGuid)
>        {
>            string query = @"SELECT p.*, s.Score 
>                            FROM [dbo].[BlogPost] p
>                            LEFT JOIN [dbo].[BlogPostReputationScore] s on s.PostGuid = p.PostGuid
>                            WHERE PostGuid = @PostGuid";
>            SqlDao dao = new SqlDao();
>            SqlCommand command = dao.GetSqlCommand(query);
>            command.Parameters.Add(dao.CreateParameter("@PostGuid", postGuid));
>            return dao.GetSingle<BlogPost>(command);
>        }
>

>
>Now, imagine that you had all the SQL and the the parameters available in metadata. And that the SqlDao had (as it has, or can have) places to put triggers, which I've also already got in metadata. As I said, I believe I can get this framework to do what I want without a great deal of effort. I'll end up generating a bunch of assemblies (one for each entity; one for each view), but that's fine. Of course in VFP.Net I could make it all dynamic, and make things much more coherent. If that's available, that's what I'll do.
>
>As for "sticking with" ADO.Net. Well, it's not ADO.Net, it's AAPL, which is a bit of a different animal. Still, it's not Linq or an ORM, both of which are very popular. But the abstractions they represent just don't do it for me. A typical advantage given is that this new method can access various databases without changing any code. So can I, already, using VFP: the only trick has been to convert, for SQL Server, the WHERE clause to SQL-Serverish, which we already do, including inline case, etc. So ADO suits me just fine, in fact I prefer to not be insulated from the reality of accessing the database -- because trying to adjust anything while wearing insulated gloves is a nightmare. Every month, often week, I read of some insufficiency of Linq or of EF, etc. And the hoops that must be jumped to make it work right. Heck, if my stuff doesn't work right, I recode that little bit to work right, and I'm done. As for creating the database, I already use metadata to create the database during the build process; already use metadata to update the database in place, including type conversions that SQL does not natively allow, so I'm not about to go backwards with that stuff. I realize this approach isn't for everyone (I don't think it would work with any other tool than xCase, because of its ability to manage information and metadata extensibility), and it doesn't work without a bunch of framework stuff that implements triggers, etc. But put all those together, and that's where you'll find me, whether it's VFP.Net (my obvious preference) or it's C#.
>
>Hank
>