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.
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 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 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 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.