As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Me and my team are going to start a new Project and we are at the stage of exploring and testing some new (or not so new) technologies.
Till today we were using classic ADO with DBDataReaders, proxies for lazy loading and in some cases DataTables.
The team consists of 3 developers and one Database designer.
Our projects consists at least 130 tables each.
Our new project has the potential to grow so we expect 100 tables for sure.
I have been reading and doing some simple testing with EF5 the last 2 days and i still can't decide if we should use it.
We usually split a big Project into many "module" projects allowing us to work faster and better under source control. Are we going to use one big "edmx" for the whole DB?
Since we have a Database Designer i suspect that CodeFirst is not an option.. So is it worth to use EF with the Database First approach?
If we use the Database first approach is the EF smart enough to detect all the relationships correctly and be ready for usage with no more additional configuration by me? (By extra configurations i mean i will have to write DataAnnotations or have to ovveride the DbContext)
Personally i find my self very confident about designing a Database with sql. The only annoyance i have is when i have to update all of the select, delete, update, insert scripts when an entity is changed in my classes-Lists.
EF will take care this for me but except this i'm starting to believe that it will slow down the performance and eventually slow down my production since we are not familiar with it..
What do you think IS IT WORTH IT ?
*Except the DataAnnotations and the DbContext ovveride, is anyone using plain T4 templates to create the tables(schema)?
I'd absolutely recommend to create multiple models. You can select which tables, views, and stored procedures to map for each.
Database first is absolutely fine.
If the database constraints have been set then EF will recognize them. You won't get around minor modifications, but all in all EF does a pretty good job.
Using EF will have a slight impact on query performance. But in most cases that won't be an issue. In the few cases where you may have an unacceptable performance hit, you can optimize by injecting your own SQL into EF where necessary.
I think, you'll become familiar with the usage of EF pretty quickly, therefore I don't think unfamiliarity will be an issue for long.
I decided not to use the EF.
I am not going to take the risk of using it in a big project.
All the work needed to use it, the possibility of dealing with bugs, the extra overhead..
I prefer writing more sql code and spend more time maintaining, than dealing with the generated models or checking the sql profiler for the generated queries..
Thank you all for your comments..
*Before i go to straight ADO again i will give a shot to FluentData and Dapper..
I will open a new question so if you guys wanna comment on these two light ORMs, i will post the link later.
If your database structure is mature, EF should be a good solution for you.
If the database structure is being developed, or will change alot over time, I would assert that EF may not be the best for you.
EF needs to be refreshed when there are structural changes (and potentially interface changes at the database layer). You should consider how you will manage database changes within your already developed code base.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
My game is turnbased, but it does have some realtime elements like chat, so it needs to be speedy. One server should ideally support a couple thousand online players.
I know Datasets tend to store large amounts of data in memory but I figured that's what I needed to avoid having to do db calls twice every milliscecond. I'm leaning away from Entity Framework because I don't seem to have as much control of whats happens under the hood, and it struck me as less efficient somehow.
Now I know neither of these (nor c# in general) are the most blazingly fast solution to ever exist in life but I do need a little convenience.
By the way I can't easily use .Net 4.0 because of some other iffy dependencies. Those could be fixed but to be honest I don't feel like investing the time in figuring it out. I rather just stick with 3.5 which my dependencies work well with.
I have done a game with a database back-end.
Word to the wise: updating caches in a real-time game is difficult. Your players will be interacting all the time. You have to think about whether you want to keep all players on the same server - if so, caching is simple, but you will limit growth. If not, think how you can keep people interacting on the same server. A chat server, for example, would solve the chat issues. However if you have geography, you might want to segment by world areas, if you don't, might want to keep groups of players, or if you have different game instances, you can segment by that.
Another issue is locking - your players might access the same data that another is updating. You will almost certainly have to deal with transaction isolation levels - i. e. read uncommitted will help with locking. For this, ADO offers more control.
However EF lets you write much cleaner update code, and the performance will not be different if you are updating by ID.
You could go for a mix - read via ADO and write via EF. You could even write a transactional db context that uses ADO underneath. That way they look alike but do different things in the background.
Just my thoughts, I hope this helps you figure out your solution.
If your only problem is the chat you can choose different kind of solutions for it, using external cloud systems that provied messeging and breadcasting...
Check out this link :
http://www.pubnub.com/solutions/how-pubnub-works
Hoped i helped at some way
It does not sound like either solution is an ideal fit for your problem. Your question is therefore like asking whether to use a wet newspaper or an umbrella to drive a nail into the wall.. regardless of the answer, you probably should do neither.
EF comes with a lot of limitations and quirks, and does have some overhead. If you really want to stick to 3.5 (poor choice in my opinion, but hey), then I wouldn't recommend it - unless you are already comfortable with it, including how to troubleshoot any performance issues.
DataSets are just an abomination. It is my professional belief that they were invented in order for Microsoft to be able to pull of their 5-minute drag-and-drop coding demos for Visual Studio, in order to convince all the VB programmers to switch to .NET. They are exceptionally slow compared to just about everything (although since .NET 2.0 performance does at least scale linearly).
I am not sure exactly what product you should be using, but I know there are in-memory relational databases that allow you to store transaction logs and the occasional snapshot, in order to facilitate rollback in case your server dies (or IIS is restarted, etc.), which gives you performance at the cost of scalability (your entire database must fit in memory).
Another option is to use a NoSQL database (such as MongoDB), which scales really well across multiple servers, and lets you bundle all related data into a single document (so you don't have all the overhead of joining tables when querying for data).
Either one of these options are going to be a much better fit than any of the two original suggestions.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have dome some seriously complex projects using the traditional WebForms and Stored procedures. Recently, however, I did a project using MVC and Entity Framework and I liked they way it works with Entity framework. They way its lets you deal with entities in object oriented manner...Its awesome. The project was not very complex. Just about 12 -15 tables.
We all know that WebForms and stored procedures are more mature and hence reliable technologies of doing thing. With my knowledge EF is still evolving. It doesn't even have the very basic "Unique Constraints". Although there are work around for things, It make's me think twice before starting a project with EF.
What I want to ask is, If I want to start another huge and complex project, can I chose to go with MVC & EF ? Is there any risk of hitting a dead end ?
Personally I use EF and MVC for every one of my new projects. I have yet to encounter a drawback. On the contrary, I find MVC far better to work with. With regards to your stored procedures, they are still and always will be more efficient than running TSQL ad-hoc.. just replace your normal ADO.NET code with EF and continue using the stored procedures. As for unique constrains, you still do those in the DB itself. More info here:
Unique constraint in Entity Framework
and here:
Does Entity Framework 5 support unique constraints?
Also, check this link for using stored procs and ad-hoc TSQL queries with EF: http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/advanced-entity-framework-scenarios-for-an-mvc-web-application
There is little risk of using EF and MVC for complex projects. If you use EF, you can still call stored procedures or execute dynamic sql queries (not that you should). EF gives you options. There maybe more risk of not using it. Don't forget SO is built with MVC.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is using Linq make it more expensive to maintain/upgrade my projects at a later stage?
Before I would have used stored procedures which are easy to modify after the code has gone to production.
I'm working for a customer who has legacy applications with lots of inline sql. They have paid to get these into stored procedures for applications where they require fast response times. And they are not excited by the prospect of using Linq seeing as it looks like inline sql to them as well.
Is Linq equivalent to inline sql? I know that Linq will make my life easier, but what about a year or two down the line?
As long as the expression is more clear and easier to understand now, then I'm quite sure it will be easier to maintain in the future.
The only downside I've found to using Entity Framework is if you need to make an emergency change (let's say), you're looking at a code change instead of just modifying a stored procedure. For our environments, making a script change to a database is much easier than pushing out new code. So it somewhat comes down to which you'd prefer in your environment, pushing a new .dll, or pushing a stored procedure change.
As for maintainability, we've been using Entity Framework for quite some time and have had zero upgrade / maintainability issues. It's easy to write, easy to maintain, and if you write your Linq correctly, easy to update / change.
In applications where everything is stored proc based, new functionality has to be both coded and scripted - which can be a pain to roll out. With the newer way of doing things it can often be a case of exposing a new function using a different linq expression - the pain of creating new stored procs and upgrade scripts goes away. (Of course the code still needs to be rolled out..)
The speed, in my opionion, is negligible - a stored proc will certainly be quicker and EF doesn't always come up with the best sql, but from it can make life simple: if I have a middle/data tier for returning a customer by ID and I want to get a customer by name; I need a new method, new stored procedure, scripts to roll this out, etc.
Whereas using EF, I can just add a new method.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm looking for a good ORM for an upcoming project.
The database will have around 1000 to 1200 tables, and it will be in Both SQL Server and Oracle, which will be used depending of customers enterprise needs.
Also a few part of the project will work with WCF services.
I want a designer or something like that.
Good support of LINQ.
Acceptable performance.
I have tried DataObjects.Net but it doesn't have any designer. We can't code all that tables nor use code generator. And I'm not sure if DataObjects.Net supports switching database.
Also I'm familiar with EF4 but it can't support both databases together, and switching databases manually(modifying the edmx file) is such a pain in ... for maintenance job.
Thanks in advance.
Edit: Seems OpenAccess and LLBLGEN Pro have designer but I don't have experience with them.
I would still vote for Entity Framework v4 - EF4.
After all:
you can have multiple EDMX files, no problem - one for SQL Server, one for Oracle
you could put those into their own class library, and then load or, or the other, or both, if needed, at runtime (e.g. by using the Managed Extensibility Framework or something of your own)
you can easily target those EDMX files at databases using connection strings - really not hard at all
OpenAccess can also do the job for you. You could use the multiple .rlinq files and assembly-per-database approach as suggested with Entity Framework. The benefit I see for you would be the support you will get from Telerik as there is quite a chance for you to hit a rock or two while developing a solution of such proportions.
Given this information I would suggest to look into NHibernate (and/or fluent-nhibernate).
The item you will have to look into is performance. This depends heavily on the nature of your application. 1,000 to 1,200 tables sounds massive, so I'd recommend to definitely run a number of meaningful performance tests (in addition to all the other tests) before you finalize the decision.
Edit: In fact the better starting place for NHibernate is nhibernate.info (Thanks, Justin!).
I think you'll need to pick your ORM and designer tool separately. For example, go with EF and LLBLGEN, or NHibernate and CodeSmith, or NHibernate and LLBLGEN, etc.
I would also suggest NHibernate but the place to research it is definitely NHForge:
http://nhibernate.info/
Here is the high-level feature overview (including LINQ):
http://nhibernate.info/doc/nhibernate-features.html
There are a few designers available, including LLBLGen Pro:
http://nhibernate.info/doc/commercial-product-ecosystem.html
NHibernate 3 is in alpha now but I know that it is already being used in production a few places. That might be the best way to go for a new project.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
If starting a new project what would you use for your ORM NHibernate or LINQ and why. What are the pros and cons of each.
edit: LINQ to SQL not just LINQ (thanks #Jon Limjap)
I have asked myself a very similar question except that instead of NHibernate I was thinking about WilsonORM which I have consider pretty nice.
It seems to me that there are many important differences.
LINQ:
is not a complete ORM tool (you can get there with some additional libraries like the latest Entity framework - I personally consider the architecture of this latest technology from MS to be about 10 years old when compared with other ORM frameworks)
is primarily querying "language" supporting intellisense (compiler will check the syntax of your query)
is primarily used with Microsoft SQL Server
is closed source
NHibernate:
is ORM tool
has pretty limited querying language without intellisense
can be used with almost any DBMS for which you have a DB provider
is open source
It really depends. If you develop a Rich (Windows) desktop application where you need to construct objects, work with them and at the end persist their changes, then I would recommend ORM framework like NHibernate.
If you develop a Web application that usually just query data and only occasionally writes some data back to the DB then I would recommend good querying language like Linq.
So as always, it depends. :-)
Errr... there's LINQ for NHibernate.
Perhaps what you mean is which to use:
LINQ to SQL
NHibernate
I prefer NHibernate.
LINQ to SQL is fairly lightweight, but it's a little bit more tightly coupled to your data structure, as opposed to NHibernate which is pretty flexible in terms of the types of object definitions that can be mapped to your table structures.
Of course that's not to say that LINQ to SQL has no uses: this very website uses it. I believe that it's quite useful to get up and running in small applications where the database schema is not as massive.
Start with NHibernate is a bad idea. It shows a good performance only with ably settings. Try to use EFv4 for large projects and L2S (maybe 3rd-part products) for small and medium size. These products are more convenient and flexible than NHibernate and allow you to start quickly.
not a complete list
LinqToSQL
Pro:
better tool support
good linq provider
easy to start with when db-schema == classes -
Con:
not flexible (ie db-schema != classes)
only supports MS SQL Server
no cascading (save, update ... doesnt cascade to referenced objects)
NHibernate
Pro:
a lot rdbms supported ootb
feature rich
very flexible for almost all corner cases
open source
Con:
not so easy to start with
not from MS
there are many tools, but you have to search for
Between the 2 ORMs
i would choose LinqToSql if:
db-schema == classes
only ever use MS SQL Server
shop only allows MS-Products
i would choose Nhibernate if:
richer objectmodel
legacy db-schema
DB other than MS SQL Server or support multiple
performance critical (i think NH has more features to optimise performance than LinqToSql)
NOTE: this is my personal view. I deal mostly with (crazy) legacy dbs and complex ETL jobs where the object model helps a lot over SQL.
I don't use (or even know) NHibernate, I just want to give my testimony: I use LINQ to SQL since about 2 years with MySQL and PostgreSQL databases (using DbLinq on Windows, using Mono on Linux and Mac OS X).
So LINQ to SQL is NOT limited to Microsoft products.
I can confirm that LINQ to SQL is very well suited for small and medium projects, or large projects where you have the absolute control of the database structure.
As the reviews indicate, LINQ to SQL has some limitations that make it an inappropriate tool when there is no direct mapping between the database tables and the entity classes.
Note : LINQ to SQL doesn't support many-to-many relationships (but this can be easily achieved with a few code lines).
The main drawback of NHibernate is the inability to make use of method calls. They cannot be translated to SQL. To circumvent that, you have to recreate expression trees which is difficult to do.