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 5 years ago.
Improve this question
Suppose you would develop a big enterprise application with complex business logic and over 100 entities where each of them has 15 properties.
Would you say that Entity Framework is suitable in this case. Or will it cause too much headaches?
Yes I know this question is opinion based. But that is exactly what I want, the opinion of the developers who have been working with big projects.
We use EF with a fairly large database, well over 100 entities, many of them with a lot more than 15 properties.
Any ORM is going to be slower than raw SQL, but you have to balance the benefits. If you find performance is an issue, you can address specific areas and optimise them. For example, if you have an entity with a lot of properties, and you query it like this...
var jim = ctx.MyEntities;
...you may see performance suffer as the number of entries in the table grows. If you modify your query to do this...
var jim = ctx.MyEntities
.Select(j => new{
Jim1 = j.Jim1,
// other properties as needed
});
...and only pull out the properties you actually need, you'll find it a lot faster.
Hope that helps.
Like anything, it's fine provided you use it appropriately.
Personally I have not hit any scale problems while using it for OLTP where it makes for great savings in development time and quality, albeit at the expense of some relatively minor inefficiencies.
Where it has let me down is bulk/batch processes, reporting and other large aggregations, even when the resulting rows can be small. In these cases it's well worth stepping out of pure EF and adding some views or stored procedures. These can then be used through EF with the typical benefits.
Keep an open mind and play to its strengths, be flexible and you should be ok.
Related
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 3 years ago.
Improve this question
I am beginner to .net core. And I am working on an enterprise application where there are multiple classes interfaces for multiple project inside a one solution. i know Entity Framework won't be a good idea if we are facing huge number of wrappers. But indeed its giving me efficiency of coding. On the other side of it Entity SQL has its own benefits.
But still want to really understand the best practice and which one to implement when it comes to Enterprise application knowing it will have number of classes, Data filtration, Generic Types, Flexibility, performance vise when querying DB.
Looking forward to get some really helpful understanding from experts. Thanks in advance.
TL;DR;
The "best practices" depends on the use case. Its a set of tools, not a silver bullet.
Sometimes EF works for your case, sometimes not. Sometimes you want a monolith, sometimes you dont.
Try, experiment fail and succeed.
Best practices regarding to techniques are irrelevant; implementation change all the time. So;
define functional requirements
define none functional requirements
do a PoC with some relevant loads etc.
At enterprise level consider these additional properties:
security
operational functionality
cloud / none-cloud
This is the best I can do, given your question.
Explain the case and we could give some direction; but its not a template fitted for all cases.
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
LINQ just seems to generate horrendously optimised SQL (in general). I can write way more efficient T-SQL myself.
Do huge websites with my thousands of daily visitors use LINQ? Or should LINQ at some point be ditched? And if so, with what? and when?
Do huge websites with my thousands of daily visitors use LINQ?
Yes. Why not? Most SQL is trivial and you can always fall back to a stored procedure where it matters.
And that is the point. Let LINQ handlethe easy 80% and focus on the more complex.
And ther rest you handle by not talking to the database - caching is not that hard to plan for.
What I have done with my apps, when L2S or EF creates inefficient T-SQL is to create a view that does exactly what I want, in an efficient manner and I just have L2S or EF query the view.
In fact, this website (stackoverflow) uses linq2sql extensively, although I believe they are using a micro-orm (sqlfu?) for some of the heavier taks..
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'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.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
So I am starting up an MVC application with entity framework and have invited a friend who is more database heavy into the project and he suggested ditching entity framework and using reflection as an ORM (object relational mapper). Does anyone have any good web posts or literature to provide that would compare the two techniques and list out pro's / con's to both?
An ORM is a big complex product with lots of services, such as:
materialization
lazy loading
persistence (including sequencing)
change tracking
identity management
query abstraction (DSLs, LINQ/expression trees, etc)
model abstraction (non-trivial mappings between the domain model and the data model)
database vendor abstraction
Reflection can provide a small part of that - in particular it can help with materialization and inspection (for persistence etc), but not all the ORM features. Now, in a lot of cases you don't need all those features - which is fine. But reflection is (comparatively speaking): slow. Which is why tools like ORMs use a large amount of meta-programming to make them fast; and trust me - you really don't want to write lots of meta-programming code unless you are experienced in that area.
But: this is a solved problem - even if you don't want to use a full ORM, the areas touched upon by "reflection" are addressed by the smaller, simpler "micro-ORM"s - things like "dapper", "peta-poco", "simple.data". Before you go reinventing the wheel: try one of the micro-ORMs. They are a lot smaller and simpler, and usually quite noticeably faster than the full ORMs - and as the trade-off they don't offer the full wealth of services that full ORMs offer.