Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Status of .NET Extender for VFP by Etecnologia?
Message
From
22/02/2010 01:02:52
 
 
To
22/02/2010 00:44:42
General information
Forum:
Visual FoxPro
Category:
Visual FoxPro and .NET
Environment versions
Visual FoxPro:
VFP 9 SP2
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01448735
Message ID:
01450167
Views:
144
haha, I can take the rest of the week off then

When you get there, I would time the compilation. You can then decide whether you need to compile for distribution or not

I haven't looked at mono - .net alone is quite a mouthful

success,



>Thanks, Greg: you just earned everything I'm paying you this week. Oh, I'm not? Well, thanks even more then!
>
>Seriously <s>, it turns out that Mono has already implemented it, but I wouldn't have been aware of that if you hadn't pointed me in that direction. http://www.mono-project.com/CsharpRepl And you are oh, so right. All I have to create are the strong types for intellisense; all the rest (including all the trigger code, and UI metadata) can be generated and compiled as needed, at least in the Dev environment (for distribution, the option will be there to compile everything for distribution). Of course I would do this as straight evaluation expression, or execscript(), in VFP, and presumably VFP.Net.
>
>And bless the Fox Team for having put the compiler in the product as of, what, VFP 5? That took a lot of guts.
>
>Hank
>
>>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
>>>
Gregory
Previous
Reply
Map
View

Click here to load this message in the networking platform