hi Hank,

Thanks - I'll look into that. Since I haven't begun I'm open to all options

Am I reading right that you use xCase to make the model, and then map that model to a database ?

Gregory
_
>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
>
>>Hank,
>>
>>Which codeplex project are you talking about ? http://rapidentityframework.codeplex.com/ by any chance ?
>>
>>
>>
>>>Hi Dennis,
>>>
>>>since I retired from psychology, I work hard not to hypothesize about others' motivations, since I'm not being paid to do so. <s> I have to admit if I were in the position many others are, I would likely feel as you describe, but I can't speak for others, and every one is an individual.
>>>
>>>As for the win-win: I couldn't agree more. I was told by an MS PM 3 years ago, I think, that it would be at least this (VS2010) or next (VS2012 from what I read) version of the tools before .Net approximated the development and language facilities of VFP. And it was just in the last month that a codeplex project was created with a lightweight data persistence framework that I know I can convert to use our existing metadata (sans the VFP code which would have to be converted), and be able to run against any backend using our existing tools.
>>>
>>>My observation, and that of others, about complex systems is that it take 10 years to mature. This applies to complex jobs and skills, but I think applies to complex products as well. .Net is coming up on 10 years, and it's starting to get there. When I read the 1.0 books (I can remember the afternoon, where I was sitting, what kind of day it was, when the first 3 arrived and I pored over them), I knew (with a sinking feeling) that it was going to be a long haul before it matured. From my own experience, it then takes about 5 to 7 years more, beyond initial maturity, to fulfill the capabilities of the system. If that holds, .Net will be "there" in 6 to 8 more years. And when it gets there, there will be dynamic languages that directly access data. I'm willing to bet any and all a pizza on that prediction. <s>
>>>
>>>Hank
>>>