We Keep Coding

Entity Framework with a Large Project [closed]

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.

What is the difference between Linq, DLinq and XLinq? [closed]

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 am reading about Linq. Please explain to me how Linq, DLinq and XLinq are different.

Linq is the base language extension which lets you query data collections using sql-like syntax. The big advantage is that it is written next to your code in the Visual Studio environment so the concepts of sql data access have been promoted to first level language constructs. This means you get all the intellisense and other cool advantages of working in VS.
So like I said, Linq is the basic technology. You can use this to query virtually anything. In plain vanilla form you can just access data like arrays
DLinq is what linq to sql was called when it was in development.
Linq to sql is a way of mapping your database to a data context and then you can use linq to access your tables in your database and make changes. It is a pretty cool technology but unfortunately it is out of date now and is being "discontinued" by Microsoft in favour of Entity Framework (which is Linq to Entities).
When I say discontinued what I mean is this: they have said they will do more features after asp.net 4.0 but they are going to put main development emphasis on Entity Framework and lots of Microsoft apps are going to be converted to use Entity Framework.
XLinq as you might have guessed by now is a way of querying Xml files with Linq.
Here is a tutorial introducing it.

Both DLinq and XLinq are just extensions for Linq:
Linq is a programming model that introduces queries
as a first-class concept into any Microsoft .NET language
DLinq is an extension to Linq that allows querying a database
and do object-relational mapping.
XLinq is an extension to Linq that allows querying XML documents,
as well as creating or transforming XML.

Official MSDN link for linq where you can get anything you want.....
LINQ is a set of extensions to the .NET Framework that encompass language-integrated query, set, and transform operations. It extends C# and Visual Basic with native language syntax for queries and provides class libraries to take advantage of these capabilities.
Where as other are flavor of the Linq you can also create you own if you want.
Dlinq is for the SQL to linq
Xlinq is for the Linq to XML

LINQ Queries in C# [closed]

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.
Why we need LINQ in C# , if we can do anything using ADO.net. Then what is the need of LINQ queries?
Are they optimized enough than ADO.net? Which is best one to use?

Personally I think that Linq greatest strength is that it optimizes the developer. It's beauty lies in freeing the developer query over variety of data sources using the same query language extensions.
You can answer how many classes are in the System.Web namespace or how many customers in our database are in Ottawa using virtually the same syntax.
Of course that comes at a cost but isn't that what optimization means?

We can't tell you why you need LINQ. That's for you to decide. Also there is a difference between LINQ and what you perceive as LINQ. LINQ does not solely mean querying SQL. LINQ is built into the compiler to translate query statements into method calls, and there are many providers that you can use with LINQ, Linq-to-Sql is one of them (I believe this is what you are referring to), Entity Framework is another, Linq-to-Objects is another, Linq-to-Xml etc.
Linq-to-Sql (and EF) are ORM frameworks used to map database objects from your database domain to your application domain. ORM frameworks can greatly reduce development time whilst providing automatic data loading, property mapping, relationship aware models, etc.
You can do all of this with vanilla ADO.NET too, but you have to roll your own. My question to you would be, is it feasible for you to use an ORM framework in your project when you consider a) your existing codebase, b) development deadlines, c) maintainability.

Linq to Sql (which I assume is what you are referring to), is useful because it provides a convenient abstraction.
It is far simpler to write a linq query than to write sql, and then hydrate an object manually.

Composability: allows you to compose queries dynamically using different code paths without resorting to complicated and fragile SQL string concatenation
Type Safety: The classes generated by LINQ to SQL or Entity Framework are strongly typed, and so type checks are enforced at compile time.
Staying in the Object Oriented world: you program in an object oriented language, why not access data in an object oriented fashion? Navigation properties allow you to get all the orders of a customer without writing a single query: cust1.Orders.
Readability: LINQ, using query comprehension or extension method syntax, is much more readable then embedding a mismatched DSL such as SQL into existing .NET code.
Rapid Application Development (RAD): With L2S/EF and LINQ, you can hit the ground running. You can get a database-connected application up and running in no-time.
Abstraction: Using a single tool, LINQ, you can access various types of data, and even create a query across multiple domains: Various databases, objects, XML, 34 more...
Database Generation: if you thought an O/R mapper only maps a database to objects, you thought wrong - it can work the other way too. EF can automatically create a database based on the classes you've created. That can be a reasonably good starting point, or even good enough for small systems.

DataTable provides you a cache that
can be re-enumerated without DB
roundtrip while LINQ to SQL results
need to be explicitly cached with
something like a ToList()/ToArray().
Identity caching in DataContext aside,
the L2S code is closer to enumerating
a DataReader. Although DataReader does
not allow you to re-enumerate and
requires another ExecuteReader, the
impact of reenumerating L2S query is
the same – another roundtrip to DB.
http://blogs.msdn.com/b/wriju/archive/2008/07/14/linq-to-sql-vs-ado-net-a-comparison.aspx
LINQ to SQL vs ADO.Net

What is best ORM with these requirements [closed]

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.

Entity Framework or something else? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am just switching from C to C# and would like to invest sometime learning database work. I am overwhelmed with the options: Linq-to-sql, ADO.NET. nHibernate, EntityFramework, plain old sql (I am used to this). Since I have only limited 'learning' hours available (about 2.5 hours per day), where should I invest my time?
I don't want to learn something that will be obsolete next month or for which no one will hire me.
If I learn EF, will this knowledge be easily transferrable to nHibernate?
Update: I decided to start with nHibernate. While EF 4.0 has fixed many shortcomings, I don't have VS2010 right now and won;t have it for another 1 year. So nHibernate is the man for now.

Personally, I think NHibernate (plus FluentNHibernate and Linq to NHibernate) lets me keep the most sanity. In real world projects, managing a single EDMX file for a large data model in Entity Framework is really painful across a large team; in NHibernate, Fluent lets you separate things across multiple C# files, or the HBM xml format allows you do use multiple XML files. The last time I used the Entity Framework, that wasn't easy unless you had separate DataContexts for each model. (If that's changed in some way recently, I apologize for my ignorance). The most difficult thing about NHibernate will probably bite you in most ORM tools in one way or another: mapping object graphs to relational models is tricky. But you get an awful lot of control over things like lazy loading, parent/child relationships, and so on; mapping by convention is also a huge win if you're using Fluent.
But you won't go broke picking the tool that Microsoft is investing in; a lot of companies didn't even seriously consider using an ORM until the Entity Framework was released. Personally, I don't really want to work for companies that defer decisions like this until their vendor finds a passable solution, but the fact is, a lot of companies do (or will) use the Entity Framework.
There's absolutely nothing wrong with using the Entity Framework, although I suspect that if you used EF in anger for a real-world project for 4 weeks, and NHibernate in anger for about 4 weeks, with multiple developers on the project, there's a good chance you'd find NHibernate simpler. In my experience, EF looks much simpler at first, but gets hairier the longer you use it. NHibernate looks and feels much harder at first, but gets simpler and more obvious the longer you use it.

Rather than pick something you think you might be hired for, focus on EF (perhaps) as a concrete example of a solution to the ORM problem as a whole. In spite of leaning EF your future employer might be an nHibernate house, or have their own home-grown solution. Learn EF, but use that experience to learn the ins and outs of ORM.

EntityFramework is what Microsoft is showing as their proposed database technology. It incorpates a lot of what Linq-to-Sql does. I would start there along with ADO.NET. You'll encounter ADO.NET a lot as well.
Like the comment says too Linq-to-sql isn't being advanced anymore either.
http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx#ado.netenfrmovw_topic2

If you wish to explore Entity Framework, this series of Pluralsight videos by Julie Lerman demonstrates many of the basics you'll need to get going. As Kevin mentioned, Microsoft is putting less emphasis on LINQ-to-SQL and more on LINQ-to-EF.

NHibernate has greater flexibility in inheritance mapping, better integration with stored procs / database functions / custom SQL / triggers, support for formula properties and it just a more mature platform than EF 4.

(sorry for the long post ahead, but I decided to try to give a bit of background to two of the main frameworks)
I'd like to add that using a non-Microsoft technology has the advantage of creating a larger birds-eye view of the problem and prevents you from locking yourself into that .NET + Entity + SQL Server cycle (even though Entity is database agnostic).
You might consider NHibernate. It's arguably one of the most mature open source ORM frameworks available. It is fast and it is used by large and very large enterprises. There also lies its greatest weakness: NHibernate is considered to have a rather steep learning curve. If you take this path, I can recommend the excellent book "NHibernate In Action" published by Manning.
Many of the weak points of NHibernate have been taken away from two sides: best practice ORM enterprise have been implemented in the S#arp architecture (downloads at Github now), which also covers fully automated mapping from database to MVC architecture. S#arp Architecture makes complex NHibernate scenario's a breeze (but still has a steep learning curve).
On the other side is the easy-configuration part through Fluent NHibernate, which creates a "one point of maintenance" situation: just code your entity objects in C#, call Config and the database is created if it doesn't exist. Saves you a hell of a lot of time. Fluent really makes working with NHibernate as it always should've been (and actually, as EF could've been).
Note that, unless it has changed recently, that Entity Framework requires changes to the database for the stored procedures, which is why I personally rarely applied it. Also, EF does not scale too well in enterprises unless you add a lot of effort yourself. NHibernate shines when you have an existing database, need it for large enterprises, or do not want to change what you've already created (incl. triggers, SP's, constraints).
From a learning perspective: as others have said, learning EF is a good start, it is rather easy and there's ample documentation. Smaller organizations are more likely to use EF because of the ease-of-use. Medium sized to large companies are more likely to go to NHibernate (and comparable enterprise-minded mapping systems). EF is rather new, NHibernate has a long history. Both have their merits. Both work well with LINQ. Both are (very) good to understand well and find a place on your CV.

I'm in the same boat as you, I found the Summer of NHibernate series really useful.
http://summerofnhibernate.com/
Thanks
-Hem