Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Crystal and SQL
Message
De
15/07/2014 16:03:18
 
 
À
15/07/2014 15:49:25
Information générale
Forum:
Visual FoxPro
Catégorie:
Crystal Reports
Titre:
Versions des environnements
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Network:
Windows 2000 Server
Database:
MS SQL Server
Application:
Desktop
Divers
Thread ID:
01603687
Message ID:
01603757
Vues:
51
>WIth ADO.Net you have to create a connection object, open the connection, create a command object, etc, etc. With EF (at least code first), you can auto-generate the entities, do a tiny bit of coding to create the context, then just instantiate the context in the app. You make a simple call to insert, update, delete. Query is pretty simple too using LINQ.
>
>>Just curious, why do you say that?

In the abstract, I would agree with you. But remember, the general historical path is that Microsoft will release core functionality without necessarily providing a framework. That opens the door for third party solutions, and home-grown company solutions with varying degrees of success. Kevin McNeish's MM.NET (which I used once and generally liked) certainly paid his bills for a long time because of that. Most C# people I know who also worked with data wound up rolling their own data access frameworks, with some level of overlap. And then years later, you have a new framework from MS.

So when something like EF comes along, some developers say, "wow, this does 100 times more than what my framework did"....and others at the opposite end say, "yawn, I built a framework X years ago that does what EF does, but with less overhead". I'm probably somewhere in between, but certainly the items you mentioned in your first sentence are ones that existed in most decent DALs. So in 2014 anyone needing to do the things you described is either a pure newbie or very inefficient. And guess what, all perspectives are valid. The main context here is what developers do to survive and expand, in the period between. If someone were to write a book about the history of MS development tools, that would be a rather large part of the history.

Now, every so often something comes along and blows the doors out of what we were all doing - WCF (IMO) is better than what 99% of developers were doing beforehand in trying to create communication factories. Even if someone carved out their own factory pre-WCF that could be consumed in the same # of lines, WCF was likely still better under the hood.

That's what bothers me about these generalizations (and this isn't directed towards you, it's more a global issue). They really overlook how people have been using the tools.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform