I've been evaluating MindScape Lightspeed for the purpose of Model creation. So far I am satisfied. I was further looking for OOTB (actually some professional quality code) providers for MySQL for ASP.Net. I've come across 'dotconnect for MySQL' from Devart. This looks like fitting the bill for the latter requirement. It also has 'Entity Developer' for creating Entity Models (I discovered this a little late). I have however not evaluated this. I surely want to go ahead with dotconnect for the purpose of using various providers but I am not sure how good Entity Developer is in comparison to MindScape Lightspeed. This question stems from the fact that I am a very (ready as very very) small shop and I would like to invest smartly even if it is a matter of $100.
First off, I work for Mindscape - just to get the disclosure of the way :-) I'm not a devart customer and perhaps somebody could add additional information if they've used their tools. To state what the products are you're looking at:
Entity Developer - a designer tool for creating a model. It allows you to generate a model for LINQ to SQL or LINQ to Entities. There are already designers provided to do this by Microsoft however the tools provided by devart appear to be superior and may be worth the price if you have issues with the default tools.
dotconnect for MySQL appears to be a provider that lets the Entity Framework talk to MySQL. By default the Entity framework provides no capability for this but does provide a plugin framework so that developers can build providers (in this case, MySQL). I could be wrong here but that's how it looks. This means the ORM factor is controlled by Microsoft and you would have the capabilities and release cycle dictated by Microsoft (this can be a good or bad thing depending on your requirements :-)
LightSpeed on the other hand is a ground up ORM that Mindscape have developed. It does no re-use Microsoft technologies other than integrating our designer into Visual Studio. This means our ability to respond to requests is superior to that of Microsoft. We have baked in support for MySQL as well as many databases meaning if you purchase LightSpeed and later do another project using a different database engine you won't need to purchase another product. We have published a rough guide to the underlying differences between LightSpeed and the Entity Framework in our orm comparison document (note: it's based on comparing to the Entity Framework delivered with .NET 3.5, not the one coming out next year).
In terms of the designer, I'm not sure how they compare in detail. The LightSpeed designer has supported schema round tripping for a long time (meaning if you change the model in the designer you can push changes to the database OR if you change the database you can right click and update the model based on the database changes - whatever works for you). With LightSpeed 3.0 which we released today, we also auto track migrations so that you do not need to manually create SQL files to migrate your database schema as you evolve your solution. If you wish to alter the templates for the generated code you are welcome to do so - which seems similar to what the devart designer allows.
Having said all this - if you're looking for Visual Studio support for the basic ASP.NET controls (like table adapters) then you would likely find a better bet with the devart product because it surfaces that sort of thing better. You can technically use LightSpeed with these by wrapping LightSpeed entities with an ObjectDataSource in most cases but it's an additional step.
On the whole, I can appreciate that the products appear similar-ish but are actually quite different at the same time. I haven't listed out pro's and con's because it absolutely depends on what you're looking for and the type of project you're building. I appreciate your feedback as you find out more - let me know what you discover :-)
Also - if you have any further questions or if you'd just like to have a chat about your requirements in more detail please use the contact form on our website - I'm happy to help!
Related
We are developing LOB apps for many potential customers that are small or mid size, not large.
We will have to install the database for each new customer.
What do you think is the best approach for us, Model first (using edmx and using the wizzard to develop the model and metadata) or Code First.
We like the simplicity of Entity Framework/RIA Services, and we think that the Optimistic Concurrency is enough for our apps, but as the database must be installed from scratch in SQL Server (we won't use other database), we are not sure what approach is best for us.
As long as EF and the choice about edmx/code first I believe it's more a matter of personal preferences. Edmx model seems easier than code first however the designer is still a bit clunky even in VS2012 especially if you have 50+ entities. I've abandoned edmx since EF code first has become usable.
About WCF Ria Services I use it extensively in my LOB applications, even in a large one and most of the time it saves you a lot of glue code comparing to plain WCF. I'm sure you know about the well published features such as
server side filtering, paging and even grouping
Client code generation that ease the sharing of code between sl and the full clr
and many others, but maybe you're more interested in his limitations
you can't query from the client with a nested expression (i.e. Any) though you can always add a parameter to your query and apply the filter server side, but it's not quite the same
you can't directly expose many to many relations with silverlight (have however a look at M2M4RIA)
you must add the foreign key field to your model (to me it seems like DB leaking into the the model)
WCF Ria services do most of his work in the main thread (i.e. loading the DomainContext after a load/submitchanges)
If your application get big and you're thinking to split your domainservices/domaincontext, be aware that you'll encounter serious pain trying to submit the changes of the two domaincontext in an atomic transaction
Proxy generation will happen everytime you build your client and take (I think) longer than it should
Despite that I believe it's a good technologies for RAD and things may eventually turn better: Colin Blair has posted on his blog that him is pushing Microsoft in order to release WCF Ria as opensource, and this can really improve things given that Microsoft has killed Sl/Wcf ria development
Problem
In the past, our development team decided to create a new enterprise application and decided to use "Linq to SQL" since the Entity Framework "sucked". (Not my opinion!) They used Visual Studio 2008 and the EF wasn't part of the default setup but required an additional add-in. So the decision was made to use Linq to SQL to access the database. As a result, we now have multiple projects around a datamodule class library containing a DBML and L2SQL entities...
Needed
It is now clear that those developers were wrong. Some moved on to other companies and a few new ones are included in this project. (Including me.) And we would like to use the Entity Framework instead. Preferably version 4 with .NET 4.0... This will allow us more flexibility with our data and we're hoping to include some inheritance in several of the entities, making the code easier to read and nicer to use.
Question: How to...
So, how to migrate from "Linq to SQL" to the Entity Framework 4 without the need to rewrite much of our code?
Manually. There is no other way and if you don't have integration test suite for all projects using the data module you should not start with any migration until you write those tests because many linq queries which worked in Linq-to-Sql doesn't work in Linq-to-entities (and not only Linq queries).
Generally that migration is wrong idea. It looks like you want to make a migration just because you want to use another technology. What real business value will be added by this effort? EF and Linq-to-entities offers some additions but it is in many ways worse than Linq-to-sql. There is no need to touch code which works unless you have some real business requirement which will make this necessary. Especially migrating to EFv1 would be really stupid move. You can use .NET 4 with your current code without any problems because Linq-to-Sql is part of .NET 4 as well.
If you ask me the former developers made a good choice when they made selection between EFv1 and Linq-to-Sql.
I'm going to start a new project which is going to be small initially but may grow to big over the years. I'm strongly convinced that I'm going to use ASP.NET MVC with jQuery for UI. I want to go for MySQL as database for some reasons but worried on few things.
I'm totally new to Linq but it seems that it is easier to use once you are familiar with it.
First thing is that accessing data should be easy. So I thought I should use MySQL to Linq but somewhere I read that it is not directly supported but MySQL .NET connector adds support for EntityFramework. I don't know what are the pros and cons of it. DbLinq is what I also heard. I would love if I can implement repository pattern as it allows to apply filter in logic layer rather than in data access layer. Will it be possible if I use Entity Framework?
I'm also concerned about the performance. Someone told me that if we use Entity framework it fetches lot of data and then filter it. Is that right?
So questions basically are -
Is MySQL to Linq possible? If yes where can I get more details on it?
Pros and cons of using EntityFramework or DbLinq with MySQL?
Will it be easy to access data using EntityFramework or DbLinq with MySQL?
Will I be able to implement repository pattern which allows applying filter in logic layer rather than data access layer (when I use EntityFramework with MySQL)
Does it fetches hell lot of data from database and then apply filter on it?
If it sounds too many questions from my side in that case, if you can just let me know what you will do (with a considerable reason) in this situation as an experienced person in this area, that should answer my question.
As I am fan of ALT.NET I would recomend you to use NHibernate for your project instead of EntityFramework, you may google for the advantages over it, I am convinced you'll choose it.
Based on the points you've mentioned, then I would seriously consider going with MS SQL instead of MySQL initially and implementing LINQ-to-SQL instead of Entity Framework, and here's why:
The fact that you are anticipating a lot of traffic initially tells me that you need to think about where you plan to end up, rather than where to start. I have considerably more experience with MS SQL than I do with MySQL, but if you're talking about starting with the community version of MySQL and upgrading later, you're going to be incurring a significant expense anyway with the Enterprise version.
I have heard there is a version of LINQ that supports MySQL, but, unless things have changed recently, it is still in beta. I am completing an 18-month web-based project that used ASP.NET MVC 1.0, LINQ-to-SQL, JavaScript, jQuery, AJAX, and MS SQL. I implemented the repository pattern, view models, interfaces, unit tests and integration tests using WatiN. The combination of technologies worked very well for me, and I plan to go with the same combination for a personal project I'm developing.
When you get MS SQL with a hosting plan, you typically have the ability to create multiple databases from that single instance. It looks like they give you more storage because they give you multiple MySQL databases, but that's only because the architecture only supports the creation of one database per instance.
I won't use the Entity Framework for my ASP.NET MVC projects, because I wasn't crazy about ADO.NET in the first place. I don't want to have to open a connection, create a command object, populate a parameter collection, issue the execute method, and then iterate through a one-way reader object to get my data. Once you see how LINQ-to-SQL simplifies the process, you won't want to go back either. In the project I mentioned earlier, I have over 60 tables in the database with about 200 foreign key relationships. Because I used LINQ-to-SQL with the repository pattern in my data layer, I was able to build the application using not a single stored procedure. LINQ-to-SQL automatically protects against SQL injection attacks and support optimistic and pessimistic concurrency checking.
I don't know what your project is, but you don't want to get into a situation where you're going to have trouble scaling the application later. Code for the end result, not for the starting point, and you'll save yourself a lot of headaches later.
I'm working on an eCommerce website for a small merchant. This merchant uses Opera (which is based on Visual FoxPro) to manage his in-store inventory, and would like the online store inventory to reflect the in-store inventory.
I'm guessing that my first step is to set up a way to regularly transfer the information from the VFP database to a MySQL database on the website's server. Is there an established process for this? Am I even approaching this problem from the right angle? I've heard a lot about ODBC, but am unsure as to how to implement it or if it's what I'm looking for in this situation.
If it wasn't obvious by this point, I'm in over my head here, and would appreciate any and all advice you may have, including links to articles or tutorials that can help improve my general understanding of all the moving parts here.
Thanks much.
Co-worker developed synchronization process between VFP and MSSQL2008. WCF service which took input directly from VFP.
On other project - as far as i remember, when we tried ODBC .NET data adapter, it had problems with encodings and foreign languages. That's why we used COM+, serialization for communication with .NET.
But it seems to me you are using PHP (eCommerce=>Drupal=>PHP) so you are in completely different situation.
In your case, i would start with checking out if Opera (i guess it's this Opera) provides built-in export and eCommerce provides built-in import. Mostly because it might be tedious work to sync data manually from 2 apps coded by someone else. Then i would research if i/o can be joined and automated (something like scheduled task on win environment). Unfortunately, can't help much more because i'm unfamiliar with those tools, products and technologies.
Anyway - it seems to me like quite hard and dirty task and i wish you good luck. :)
Depend on what is that you are using to implement the website.. in general it is pretty easy with ODBC (In Java , I did it using the jdbc-odbc bridge)
I would like to know what are the principal diferences between "ADO.NET Entitiy Data Model" and "Linq to SQL Classes"? What is the best choice to work with?
I couldn't find any document on the internet explaing that and everything I know is that we can use both, "almost", in the same way.
Linq To Sql is not being actively supported by Microsoft anymore.. They have picked the Entity framework has 'the way for the future'. You can google and verify this.
Here's your friendly neighbourhood SO topic with all the good bits
Update: Hmm.. it seems that MS has taken a step back from the infamous declaration. But the message is still not clear with respect to the future of L2S.
as of .NET 4.0, LINQ to Entities will
be the recommended data access
solution for LINQ to relational
scenarios.
We also want to get your feedback on
the key experiences in LINQ to SQL
that we need to add in to LINQ to
Entities in order to enable the same
simple scenarios that brought you to
use LINQ to SQL in the first place.
That pretty much reads 'phasing out' to me. I may be guilty of reading between the lines though.. there may be hope after all... behind all the 'on-the-fence' answers
ADO.Net team blog : Update on LINQ to SQL and LINQ to Entities Roadmap
ADO.Net team blog : Clarifying the message on L2S Futures.
http://damieng.com/blog/2008/10/31/linq-to-sql-next-steps
EF classes are not persistent-ignorant. They inherit from a base class that adds a unique entity key and change tracker. This can make disconnected environments more of a pain with EF than the object generated by L2S.
This is what I can tell from personal experience (which may not be the whole story):
The learning curve for LINQ to SQL may be slightly less steep than for ADO.NET Entity Framework. Personally, I also feel that LINQ to SQL is a bit more lightweight.
Both frameworks are getting updated in the next version of the .NET framework (version 4).
If you include the features for .NET 4 then Entity Framework appear to be the more feature rich framework. Microsoft seems also very commited to this framework.
Visual Studio has quite strong support for both frameworks. For instance, if you create an ADO.NET Data Service in your project it will discover both your LINQ to SQL and Entity Framework classes.
Entity classes in the Entity Framework are derived from a specific base class in the Entity Framework. Some may consider this a showstopper for using the Entity Framework.
I find both frameworks surprisingly easy to use and I would suggest anybody interested in these technologies to play around with them. Create a .NET project of choice in Visual Studio and add both LINQ to SQL classes and an Entity Framework model connected to whatever database you have access to. Then try out both frameworks by doing things like CRUD operations etc.