Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm working on a project that we're using .NET MVC 3 and EF 4. The website is growing and there are a lot of tables. So, the table designer of Entity Framework too much CPU usage t open and add new tables. What are my options? What can I do?
For larger models, I think the designer approach is less desirable. If you can, consider refactoring (one bite at a time?) to a code-first approach; this will allow you to keep using current technology. I have a project with ~650 entities working perfectly fine, but I can't imagine loading a .edmx designer with ~650 entities (without pulling my hair, that is).
All in all, it's not EF that's "heavy" - it's the designer.
Starting with Visual Studio 2012, you can now split your Entity Model into multiple diagrams. This'll reduce the diagram complexity a lot.
See
http://msdn.microsoft.com/en-us/magazine/jj721589.aspx
http://msdn.microsoft.com/en-us/data/jj519700.aspx
If you database operations are large in general you may consider not using EF and use raw ADO.NET instead. EF boils down to ADO.NET at the low level anyway but using ADO.NET right away will improve performance.
Moving to a code first architecture is definitely something to consider for the long term. For the short term, you also might be able to break your model up into multiple design contexts. You can start this by identifying areas of the application that only use a subset of the tables. Then create a separate data context that only includes those tables. You can keep the existing omnibus context around while you're working on this to avoid breaking legacy code. You can add as many data contexts as you like, but I would create each one in a separate folder (and therefore a separate namespace) so you don't have to worry about name collisions.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am currently exploring of using Entity framework for the windows based (forms) application I'm developing that does data mining for a dataset of more than 1 million rows (my datasources are from oracle, sql server, sqlite). What the application will do is I parse these information to the users local client, and I utilize linq to objects in mining useful information. The said application shall only read information to the source database as its output is written in an excel file.
Given the significant ease of using the Entity Framework in terms of reducing the development time (this is the first time I will be using an ORM, and coding the necessary dataaccess objects takes about 80% of my time based on the previous projects I've done before), I would like to ask if it's worth it to use EntityFramework to the application I'm working in? How much would be the performance drop (as compared to using DataReaders) when reading tables for over 1 Million rows?
Also, given that I'm new to this technology, I would much appreciate it if you could refer me to useful tutorials and best practices.
Using pure ADO.NET will give you practically best performance you could get. But bear in mind that after you fetch data from data source, you would still need to map results to your object model (something that is done by EF automatically) so that you can perform actual data mining.
Mapping could be tough or easy process to do depending on how complex your data model is. For example, Entity Framework is good at mapping hierarchical data structures, which is useful when fetching related entities (or even their related entities) along with the actual entity.
You should also consider how often does your data model changes (and how big those changes are), so you calculate maintainability cost too. Having tons of SQL that you have to change every time you add new column is another point of getting problems. In this case, maintaining EF model with POCO's would be easier and more convenient.
Note that there are other O/RMs that can give you kind of best of two worlds (performance of DataReader and easy mapping to POCOs of Entity Framework). Among these are: NPoco (former PetaPoco), Dapper (the one used at StackOverflow), NHibernate (using HQL can be quite fast), OrmLite (has basic LINQ-like queries support) and many others.
Take a look at Dapper's performance benchmarks results that might give you some picture of what performance can be achieved with popular O/RMs.
Performance of either technology of fetching data is really dependent on what data model you have in the database.
That's why it's important not only to analyze existing benchmarks, but also perform your own based on your particular use cases on your data model. As a starting point, you can grab Dapper's performance tests code and tweak it according to your needs (data model, typical queries, etc), so that you get more comprehensive and realistic performance results using different frameworks.
EF is never as fast as using raw ADO.NET with an OracleCommand. After all, EF is another layer on top of ADO.NET; it's main goal is to provide programmers with convenience features of mapping raw columns into fields and rows into objects.
If you need the absolute top-notch performance, then you need to use raw ADO.NET. The downside of this is the fact that you need to start fiddling around with untyped rows and columns.
There ain't no free lunch - either you have top performance but an unpleasant programming API, or you get convenience and productivity - at a performance price.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
How Code First used with Entity Framework 4.1 ?I want to know how Database is manged and Model is used in Code First Approach.Thanks
Code-First Development enables a pretty sweet development workflow. It enables you to:
Develop without ever having to open a designer or define an XML
mapping file. Develop without ever having to open a designer or
define an XML mapping file.
Define your model objects by simply writing “plain old classes” with no base classes required.
Use a “convention over configuration” approach that enables database persistence without explicitly configuring anything.
Optionally override the convention-based persistence and use a fluent code API to fully customize the persistence mapping.
Its a general question and lot of help is available on the internet.Following link will be helpful to implement Code First Approach.
http://msdn.microsoft.com/en-us/magazine/hh126815.aspx
http://weblogs.asp.net/scottgu/code-first-development-with-entity-framework-4
With EF 4.1 the database is not managed. You can have it generate the database on your initial creation but EF 4.1 does not use Migrations. You could create a custom solution to manage the database piece but it may prove to be a pain and dangerous in a prod environment.
Not sure how familiar you are with EF but if you have not used it I would recommend as others have reading a tutorial or 3. Also, if possible I would use the newest version of EF that you can as a great deal has been updated since 4.1.
Here is a tutorial.
http://blogs.msdn.com/b/adonet/archive/2011/09/28/ef-4-2-code-first-walkthrough.aspx
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 8 years ago.
Improve this question
I'm currently learning LINQ especially SQL requests with the entity framework.
I used to write native SQL-queries before, and I've implemented it with one class in my projects called "SQL_Connection" or something.
So I had all my SQL-procedures stored in one class.
Now as I'm willed to learn the entity framework the right and cleanest way from beginning, I'm asking myself where do I put all those linq-procedures I create during a project.
Do expierienced people put them in the class-file of the related class, or are they using a big sql-class where all those procedures are stored in?
I'm asking myself where do I put all those linq-procedures I create during a project.
Where you create them.
If you are not totally ignorant on .NET you will have a TON of LINQ queries and only SOME will be EF related - the syntax is the same. You will use LINQ in your code to sum and aggregate in memory arrays, and do a lot of things.
The beauty of LINQ is that all changes to the underlying provider are isolated and / or checked by the compiler, so there is no need to have all in one place "in case I rename a table".
I keep the LINQ where I need it. This allows me to isolate layers without having a mother of all queries class. Especiall as some of the LINQ queries are multi step queries involving one or more data access then grouping and correlating in memory.
Seriously, the "one class to rule them all" (sql) is an artefact of the fact that SQL is a string, so in case of a database change you need to find all SQL that touches that changed element and that please without going through tons of code. This is absolutely not needed with LINQ.
That's up to your pleasure. Answering the question: do create BLL classes for your related set of objects. By this, a minor change won't make you itchy. Assume you added a new column to a table, having that table's (and other related ones') operations located easily is good, right? Avoid too big files. Try to stay modular and etc.
If you need a reading, check out this Wiki link about MVC architecture.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am learning C# and I want to access a database. I have been searching pages on .net database connectivity for the last two - three days. I also came to know that it has several ways for the connectivity and this is exactly where my mind started to ask a number of questions. Please tell me if I am wrong in my understanding.
Check out this Diagram 1.
Now what I am getting here are five ways of connectivity:
Linq to Objects
Linq to Datasets
Linq to SQL
Linq to Entities
Linq to XML
Here is another Diagram 2 of ADO.net Architecture -
I have read the definitions, but am not able to differentiate the functionality and purposes. Can anyone give me a short explanation of both diagrams for my understanding?
Suppose I am a programmer who write code in C#; which way should I
prefer to write desktop based has database connectivity that
has future?
To Software Developer is it needed to go through all the
preceding ways of data access from database?
For the answer to number 1, use Entity Framework and a database. The database could be relational (like SQL Server), or document-based (like MongoDb). If you just grab the free Visual Studio 2013 express and start by creating a new project from a template, you'll probably end up with some version of SQL Server to start out with.
You have a lot of options for Linq to Whatever because sometimes you just have to get data out of repository and if you can use Linq as a facade to it, then getting your data out is that much easier because it feels a lot like getting data out of a database. There's even Linq to Twitter. For a brand new project though, you'll most likely use a database.
For the answer to number 2, you would only do that on an existing application that you are maintaining. It is fine technology, but if you're creating a new project, use Entity Framework.
Under the covers of all the data libraries, every time you access the database three things happen:
- a connection is made to the database
- a command is created (to select, update, insert or delete data)
- the command is executed in the database
In the case of LINQ or EF, the SQL for the command is generated automatically from your objects, but ultimately, the same three actions happen.
If you want to understand the basics, start with the ADO.NET objects. If you want to get something running more quickly take a look at EF, or nHibernate.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Can I Use Entity Framework 6 with .net 4.5 for a big project ?
In this project i have many solution in this project and some of them are in a fast communication with database like as Smtp with hug data communication
thanks
// edit for more details
i start a big project that it has five section
1- send sms with smtp that create huge request and overload on database for example in secound 1500 record insert and select
2- payment request
3- many other request ...
The default answer, is certainly yes. This is where all ORMs shine. In large systems where writing a data access layer is a big and error prone task.
As Steve McConnell suggests in his great book you should never make speculations about performance. Therefore, if you have specific performance concerns, you should try benchmarking.
If you want my opinion, between clear code and performance, I choose clear code. It will allow you to implement a more robust and maintainable system. Then, if you identify performance problems, you could make the necessary minor changes. This is my default rule.
Hope I helped!
Can I Use Entity Framework 6 with .net 4.5 for a big project ?
Yes
In this project i have many solution in this project and some of them are in a fast communication with database like as Smtp with hug data communication
Yes, although it might depend on your database design. And even then you could use Stored Procedures if necessary.