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.
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.
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.
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 9 years ago.
I am a beginner to .Net. Recently I am working on a small practice project in which i want to interact with SQL DB using Datasets in VS .net 2008. Kindly suggest me few readings regarding Typed Datasets.
If you prefer to work with datasets (and ado.net in general), I would recommend Microsoft ADO.Net Core Reference. The book is dated now, but in my opinion, so is using datasets. Either way, you can't beat that book in my opinion. The follow up book, which covers ADO.Net 2.0 is more modern and done almost as well as the original (though the original will teach you more about how everything works).
you can google these things. however check the below links
MSDN Documents
Creation of Typed DataSet
A search in google for DataSet Examples C# turned the following results:
DataSet examples C#
Are you sure you want to use DataSet? There are a better techniques now for accessing and manipulating data.
Update:
Depending on your needs there are other ways to access data.
If you need speed - you will probably need to use SqlDataReader.
If you need ease of use, you may skip the more "core" ways of accessing data and use Entity Framework.
Retrieving data with Sql Data Reader
Getting started with Entity Framework
The difference is that SQL Data Reader is the most native way of accessing data. It it uses something like cursor you iterate over.
Entity Framework on the other hand is a fully featured OR/M solution for Microsoft Visual Studio, you basically tell Visual Studio where your data is and it will generate the data classes for you. From there - you just use those classes. It is really easy to use but it uses reflection under the hood which makes it a bit slower than the Sql Data Reader.
Hope this helps!
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.
I'm looking for a 'complete' solution for code-generation based on DDD or model first approach. Ideally, this would be a separate application or VS plugin that we could use and re-use to generate as much of the standard plumbing code as possible, preserving my custom business logic as well.
I would like to generate VS projects, including WCF sercvice app, Data layer, entity model etc. and client applications such as ASP.MVC (and/or web-forms) sites with scaffolding, windows client.
I know there are many choices like Entity Framework vs NHibernate, open-source frameworks such as S#ahrp Architecture, and there are commercial products as well. I'm open to anything as I know most of the investment will be in time.
Update:
To add to this: The Entity Framework (4.0) is a big step forward as it will generate c# business classes as well as the database schema, allowing you to focus on the 'model', which is good. Is there anything that will go one level higher to allow generation of other objects based on a (meta)model of some kind.
I'd recommend taking a look at CodeSmith. It comes with several different template frameworks like PLINQO (Linq-to-SQL), NHibernate, CSLA and .netTiers (which sounds closer to what you are looking for).
Also take a look at the video tutorials on how to use the frameworks located here.
Thanks
-Blake Niemyjski
I understand that SparxEA (Enterprise Architect) supports code generation (and the generation of models from code) but I've never actually done that with it myself.
So this should definately allow you to model your system / domain and then generate appropriate code.
It also seems to support integration with Visual Studio: http://www.sparxsystems.com.au/products/mdg/int/vs/index.html
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.