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.
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
We're working on an ASP.NET web application with C# code behind. The database is MySQL 5.1 using InnoDB. The data access layer uses ADO.NET to call stored procedures and then builds various data structures out of the result sets (no object mapping). This works fine, but it is a little verbose.
Not surprisingly, we made some mistakes when designing the first version of our data model, but the experience has made us smarter and we decided to refactor the data model. We don't have to change our data access layer, but we are considering our options for that as well.
It's been difficult for us to ignore the popularity of ORM tools these days; we feel like we are way behind or something for not being familiar with them. Not only that, but we have already designed an object model that nicely describes our data model. The main ORM tools we would consider are NHibernate, ADO.NET Entity Framework, and LINQ to SQL. We would prefer LINQ to SQL because we have read (on S.O.) that it is more light weight than full ORM tools.
We think one drawback to using an ORM tool is the learning curve, but we can already see how using LINQ could reduce the amount of code we will have to write, which could save us time in the long run. However, we are using MySQL, not SQL Server.
So my question is, would DBLinq work well enough for a production system? Or, is LINQ to SQL a compeling enough reason for us to make the move to SQL Server 2008? Incedentally, I'd prefer to use SQL Server over MySQL, but cost is the obvious drawback. After 3 years on BizSpark, we'd be on the hook for $6K. Or, should we consider other ORM tools instead? Or, should we just ignore the hype and not use an ORM tool, but maybe take advantage of LINQ to DataSet?
I searched S.O. for info on DBLinq, but only found 17 questions with the DBLinq tag, so it doesn't appear to be popular.
EDIT
Looks at though dotConnect for MySQL has support for LINQ, so that's another option.
Can anyone speak to how well that driver works for writing LINQ queries?
Check bl-toolkit. It's free, very fast and has great LINQ support. Newest addition are T4 templates for generating your data model from database.
I'm recently migrating to Linq2Sql and all my future projects will be using Linq2Sql. Having said that, I researched a lot on how to properly plug-in Linq2Sql in application design.
what to put at what layer ?
How do you design your repositories and business layer services ?
Should I use DTOs over Linq2Sql entities on interaction layer ?
what things should I be careful about ?
what problems did you face ?
I did not find any rock-solid material that really talked about one single thing and everyone have their own opinions. I'm looking forward to your ideas on how to integrate/use Linq2Sql in projects. My priority is maintenance[it should be maintenable and when multiple people work on same project] and scalabilty [it should have scope of evolution].
Thanks.
I have been using linq to entities for the last two and half years on production applications and I can say it has been a really nice experience... but that doesn’t means you should do everything with Linq.
I am going to try to give you some answers to your questions,
I think you should ask first what kind of application you want to create; once the scenario is clear you will have an odd idea of number of transactions or queries you are going to perform against the database (or repository).
Linq could be extremely useful to abstract data access, context and entities handling, but everything comes with at a cost. Objects will be created with a cost and you really need to think about this.
If your application has a ‘nice-not-too-heavy’ data access Linq will be the perfect tool to save time for your application.
If your application is entirely based on data extraction or processing, Linq will be great as well.
If your application is handling huge blocks of data (check your application) you will need to do something else to avoid creating a bunch of objects that might be useless.
What does that means? You need to know what a smart data access means... and that is leave SQL to work for you (in the case of SQL); if you are going to do lots of joints, cross information and stuff, create stored procedures that creates the data result for you and then get it using Linq or SqlCommand or SqlDataAdapters, etc...
What to put at what layer?
Since Linq gives you the data access abstraction you can pretty much place your code where the business logic demands it. There are tons of good practices of how to structure your code; Linq (as any other entity framework or data access libraries) will fit in the right spot.
Avoid whenever is possible direct linq expression in your controls (asp.net has lots of controls with linq data sources), instead wrapped your ‘query’ with a service class that can be instantiated by your code or controls as an object data source.
What have I found?
Pure Linq is not always possible on big applications or projects (so you will end up with many things in linq and some in previous more simple solutions to access your repositories) but will help you to save time.
Implementing stored procedures is a MUST if you want to deliver great quality applications.
Hope this comment helps.
Cheers.
I am working on a framework which will provide some basic functionality for a number of applications which our company is going to develop.
The framework will come with a basic database schema which will support this functionality.
Developers using the framework will be expected to extend the database schema with their own tables. Future versions of the framework will be shipped with update scripts to make any changes required.
What do you think the best way of accessing the database would be - both from within the framework and in the application itself?
I'd like to use either LINQ-to-SQL or the Entity Framework.
Taking LINQ-to-SQL, for example, I guess I could distribute a DBML file with the framework, allowing the application developer to extend it and provide a reference to the data context back to the framework?
Although it presents some new details, this is still just a versioning issue.
As you develop your system, modifications to the database must be versioned along with modifications to the code. Updates to your system should be an executable package including those database scripts and your data access assembly.
Users that wish to upgrade to the next/latest version must apply the package, which will execute all the database scripts to update the database, and replace the assembly that contains your data access layer. You may want to consider making your DAL a separate assembly for distribution purposes. You could use dependency injection to plug your DAL into your core system.
Depending on the complexity of the system, my fallback would be LINQ to SQL. It performs better overall and is simple to implement. If you expect your object model to get fairly complex, and performance is not a major factor, you may want to go with EF now rather than having to switch later. That's a cost-benefit analysis between performance, complexity, and ease of development.
HTH
I hope that you're using MS Sql in the back-end (though you are if you have Linq To SQL as an alternative).
I have some experience using L2S and some using Entity Framework. In my opinion EF is the better choice because it gives you a better approach towards OR/M and more control over the database objects.
It has full support for LINQ and also for Entity SQL which will give you more power when you need to write complicated queries.
Do NOT think about using EF with MySQL. More about that here
First a bit about the environment:
We use a program called Clearview to manage service relationships with our customers, including call center and field service work. In order to better support clients and our field technicians we also developed a web site to provide access to the service records in Clearview and reporting. Over time our need to customize the behavior and add new features led to more and more things being tied to this website and it's database.
At this point we're dealing with things like a Company being defined partly in the Clearview database and partly in the website database. For good measure we're also starting to tie the scripting for our phone system into the same website, which will require talking to the phone system's own database as well.
All of this is set up and working... BUT we don't have a good data layer to work with it all. We moved to Linq to SQL and now have two DBMLs that we can use, along with some custom classes I wrote before I'd ever heard of Linq, along with some of the old style ADO datasets. So yeah, basically things are a mess.
What I want is a data layer that provides a single front end for our applications, and on the back end manages everything into the correct database.
I had heard something about Entity Framework allowing classes to be built from multiple sources, but it turns out there can only be one database. So the question is, how could I proceed with this?
I'm currently thinking of getting the Linq To SQL classes all set for each database, then manually writing Linq compatible front ends that tie those together. Seems like a lot of work, and given Linq's limitations (such as not being able to refresh) I'm not sure it's a good idea.
Could I do something with Entity Framework that would turn out better? Should I look into another tool? Am I crazy?
The Entity Framework does give a certain measure of database independence, insofar as you can build an entity model from one database, and then connect it to a different database by using a different entity connect string. However, as you say, it's still just one database, and, moreover, it's limited to databases which support the Entity Framework. Many do, but not all of them. You could use multiple entity models within a single application in order to combine multiple databases using the Entity Framework. There is some information on this on the ADO.NET team blog. However, the Entity Framework support for doing this is, at best, in an early stage.
My approach to this problem is to abstract my use of the Entity Framework behind the Repository pattern. The most immediate benefit of this, for me, is to make unit testing very simple; instead of trying to mock my Entity model, I simply substitute a mock repository which returns IQueryables. But the same pattern is also really good for combining multiple data sources, or data sources for which there is no Entity Framework provider, such as a non-data-services-aware Web service.
So I'm not going to say, "Don't use the Entity Framework." I like it, and use it, myself. In view of recent news from Microsoft, I believe it is a better choice than LINQ to SQL. But it will not, by itself, solve the problem you describe. Use the Repository pattern.
if you want to use tools like Linq2SQl or EF and don't want to have to manage multiple DBMLS (or whaetever its called in EF or other tools), you could create views in your website database, that reference back to the ClearView or Phone system's DB.
This allows you to decouple your web site from their database structure. I believe Linq2Sql and EF can use a view as the source for an Entity. If they can't look at nHibernate.
This will also let you have composite entities that are pulled from the various data sources. There are some limitations updating views in SQL Server; however, you can define your own Instead of trigger(s) on the view which can then do the actual insert update delete statements.
L2S works with views, perfectly, in my project. You only need to make a small trick:
1. Add a secondary DB table to the current DB as a view.
2. In Designer, add a primary key attribute to a id field on the view.
3. Only now, add an association to whatever other table you want in the original DB.
Now, you might see the view available for the navigation.