Now that .NET v3.5 SP1 has been released (along with VS2008 SP1), we now have access to the .NET entity framework.

My question is this. When trying to decide between using the Entity Framework and LINQ to SQL as an ORM, what's the difference?

The way I understand it, the Entity Framework (when used with LINQ to Entities) is a 'big brother' to LINQ to SQL? If this is the case - what advantages does it have? What can it do that LINQ to SQL can't do on its own?

  • 50,943
  • 13
  • 104
  • 142
Chris Roberts
  • 18,622
  • 12
  • 60
  • 67
  • 145
    I think that the answers below should be re-examined because the long time since EF was released, so new developers who get here can get the wrong impression. EF became a GREAT and EASY tool since its early release. You just set up the connection to the DB and it's kind of 90% of all you need. Very rapid development, from experienced point of view! From there - LINQ is your best friend. It's highly customizable, MVC just love it, and to the people that say it's bad - Learn how to use it first (and get hold on LINQ as well)! – Shahar G. Aug 03 '13 at 14:21
  • 11
    Just so it's clear - it's not like you have choice now - MSFT effectively killed LINQ2SQL in favor of EF. However, the fact that MSFT open-sourced EF helped it to suck less and is definitely getting better. But for anyone getting into EF - be sure to understand that there are still lots of quirks in EF. I've posted about one - http://stackoverflow.com/questions/305092/which-method-performs-better-any-vs-count-0/11042691#11042691 – nikib3ro Aug 28 '13 at 21:09
  • 5
    @kape123, (a) LINQ to SQL is not "dead"; it's still usable; (b) LINQ to SQL is the standard data access method in Windows Phone 8 development. – Ryan Lundy Jan 28 '14 at 16:00
  • 1
    @Kyralessa Just dug up this thread.. LINQ to SQL is "dead" as in, is not officially support by Microsoft. – user3308043 May 20 '14 at 05:50
  • 10
    @user3308043, [citation needed]. – Ryan Lundy May 20 '14 at 14:01
  • 4
    @Kyralessa - As of 2010 (with the release of .NET4.0, the most recent citation I could find), [MS acknowledged that](https://msdn.microsoft.com/en-us/data/bb525059.aspx#Q3), while some investment may be made in LINQ2SQL, "the bulk of our overall investment will be in the Entity Framework." – kmote Aug 06 '15 at 23:05
  • 3
    @HameedSyed, that's not true, it's *Dapper*, it was even developed by SO (Sam Saffro). – gdoron Mar 22 '17 at 10:13
  • The only difference that matters today is: LINQ-to-SQL is dead, EF is alive and kicking. – Gert Arnold Aug 13 '22 at 09:30

17 Answers17


LINQ to SQL only supports 1 to 1 mapping of database tables, views, sprocs and functions available in Microsoft SQL Server. It's a great API to use for quick data access construction to relatively well designed SQL Server databases. LINQ2SQL was first released with C# 3.0 and .Net Framework 3.5.

LINQ to Entities (ADO.Net Entity Framework) is an ORM (Object Relational Mapper) API which allows for a broad definition of object domain models and their relationships to many different ADO.Net data providers. As such, you can mix and match a number of different database vendors, application servers or protocols to design an aggregated mash-up of objects which are constructed from a variety of tables, sources, services, etc. ADO.Net Framework was released with the .Net Framework 3.5 SP1.

This is a good introductory article on MSDN: Introducing LINQ to Relational Data

  • 6,058
  • 2
  • 19
  • 16
  • 1
    looks like you use LINQ to SQL to query in the EF – PositiveGuy Dec 29 '10 at 04:15
  • 13
    @CoffeeAddict while they are very similar in style using LINQ lambdas, each API has completely different underpinnings. For instance the way LINQ2SQL generates SQL queries allows for the use of SQL functions, whereas L2E does not, or at least did not as of 2008. – Kris Jan 31 '11 at 20:41
  • 3
    EF object oriented approach make it really easy and convinient to use, can be coded very fast, managed. For me, just the best way to acces data. – Antoine Pelletier Nov 26 '15 at 18:46
  • 12
    This answer is obsolete. Now Linq to SQL supports one2many mapping – George Lanetz Dec 29 '15 at 13:18
  • @GeorgeLanetz Do you mean the following? https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql/linq/how-to-map-database-relationships#example – bimjhi Jun 26 '21 at 10:26

I think the quick and dirty answer is that

  • LINQ to SQL is the quick-and-easy way to do it. This means you will get going quicker, and deliver quicker if you are working on something smaller.
  • Entity Framework is the all-out, no-holds-barred way to do it. This means you will take more time up-front, develop slower, and have more flexibility if you are working on something larger.
Brad Tutterow
  • 7,487
  • 3
  • 33
  • 33
  • 33
    You'll also tend to write less lines of code with L2S to accomplish the same thing as you would with EF. No lazy loading in EF means you're always checking if something was loaded or not. – Paul Mendoza Oct 14 '09 at 21:06
  • Brad, what would you suggest for an ecommerce site? I mean I can't see anything other than simple CRUDs going on there... – PositiveGuy Dec 22 '10 at 04:30
  • 2
    @CoffeeAddict obviously, the top 3 of most voted answer says L2S for simple CRUD – IsmailS Dec 28 '10 at 09:43
  • @Paul Mendoza now that EF does support lazy loading would you still say that L2S requires less lines of code? I'm currently working with L2S and considering switching to EF due to my simple CRUD application becoming something much larger and more complex. I do agree that without lazy loading EF would have been something I would stay away from. – Banford Feb 17 '11 at 15:26
  • 11
    @Banford With EF in .NET 4.0 I think that it is better than L2S. The features that were missing from EF in 3.5 that L2S had have been added to EF in .NET 4.0. Your LINQ statements now in EF in .NET 4.0 are going to look pretty much the same as those in L2S. EF gets you some extra things you can do now on top of what L2S offers. – Paul Mendoza Feb 17 '11 at 18:15
  • 42
    This answer is now 5 years old and quite outdated. Entity Framework 6 is now in Beta and is much improved, includes Lazy loading, enum support, etc, etc. – Tim Aug 01 '13 at 23:42

Is LINQ to SQL Truly Dead? by Jonathan Allen for InfoQ.com

Matt Warren describes [LINQ to SQL] as something that "was never even supposed to exist." Essentially, it was just supposed to be stand-in to help them develop LINQ until the real ORM was ready.


The scale of Entity Framework caused it to miss the .NET 3.5/Visual Studio 2008 deadline. It was completed in time for the unfortunately named ".NET 3.5 Service Pack 1", which was more like a major release than a service pack.


Developers do not like [ADO.NET Entity Framework] because of the complexity.


as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios.

  • 1
  • 1
Zack Peterson
  • 56,055
  • 78
  • 209
  • 280
  • 58
    Actually, we don't like EF because it has such a poor designer and is so extremely, *extremely* buggy. I've never found it to be all that complex. – BlueRaja - Danny Pflughoeft Apr 22 '10 at 21:10
  • 13
    A LOT of major e-commerce sites use LINQ to SQL. Examples: Redbox, Stackoverflow, etc. – PositiveGuy Dec 22 '10 at 04:30
  • 14
    I know a LOT of good developers that use LINQ to SQL and say these articles are totally overblown. I agree. LINQ to SQL has been used in powerful .coms and still is. – PositiveGuy Dec 29 '10 at 04:16
  • 4
    Yep, calling .ToString() on an integer property in a L2EF query shouldn't cause an exception. – StingyJack Mar 11 '11 at 21:43
  • 2
    IMHO if you are **relying** on a designer then you are setting yourself up for problems later i only use designers for quick setup and maintain the code there after i used to use designers but always ran into limitations and have moved on to better things such as using the code first frameworks to map existing databases to code and use ef power tools for my quick setup – Chris McGrath May 09 '12 at 13:45
  • 3
    @BlueRaja-DannyPflughoeft Is it still true after more than 5 years ? – Vikas Rana Dec 01 '15 at 12:33
  • 1
    @VikasRana the designer will still bite you in the ass if you have a merge conflict with .edmx files even in 2016, use Code First instead – Dan Aug 04 '16 at 13:12
  • 1
    Another 5 years, wondering if this still holds? I mean if I know SQL and LINQ, why can't I just do that? Should I really put the time into learning EF for a large project? – user4779 Jun 23 '20 at 09:19
  • Huh... So I was there (sort of), when the whole LINQ vs Entity Framework discussion started.... My recollection is different than Matt Warren's. There was a definite conflict between the folks on the C# team driving LINQ and the SQL team driving entity framework. There were different blog posts from different people claiming to be the "future of data access technologies". It in resulted in 2 Technical fellows bumping heads. Linq to Entity Framework was the compromise that resulted. In either case, the LINQ folks, at the time.... the did not think they "should have never existed". – Scott Wisniewski Jul 31 '20 at 10:03

There are a number of obvious differences outlined in that article @lars posted, but short answer is:

  • L2S is tightly coupled - object property to specific field of database or more correctly object mapping to a specific database schema
  • L2S will only work with SQL Server (as far as I know)
  • EF allows mapping a single class to multiple tables
  • EF will handle M-M relationships
  • EF will have ability to target any ADO.NET data provider

The original premise was L2S is for Rapid Development, and EF for more "enterprisey" n-tier applications, but that is selling L2S a little short.

  • 14,891
  • 10
  • 61
  • 93
  • 13
    Your quote "L2S will only work with SQL Server (as far as I know)" needs updating: the open source project "dblinq" replaces the LINQ to SQL assembly with one that can talk to MySQL, PostgreSQL, Ingres, Firebird, SQLite ... and Microsoft SQL (of course). – Contango Dec 24 '10 at 11:41
  • 1
    wait ...so EF doesn't create tightly coupled DL objects? – PositiveGuy Dec 30 '10 at 05:21
  • 7
    yea the original premise that L2S is not an enterprise capable solution is no longer true. I mean StackOverflow runs on L2S and a bunch of other .coms such as Redbox, and many more. – PositiveGuy Dec 30 '10 at 05:22


  1. Homogeneous datasource: SQL Server
  2. Recommended for small projects only where data structure is well designed
  3. Mapping can be changed without recompilling with SqlMetal.exe
  4. .dbml (Database Markup Language)
  5. One-to-one mapping between tables and classes
  6. Supports TPH inheritance
  7. Doesn't support complex types
  8. Storage-first approach
  9. Database-centric view of a database
  10. Created by C# team
  11. Supported but not further improvements intended

Entity Framework

  1. Heterogeneus datasource: Support many data providers
  2. Recommended for all new projects except:
    • small ones (LINQ to SQL)
    • when data source is a flat file (ADO.NET)
  3. Mapping can be changed without recompilling when setting model and mapping files Metadata Artifact Process to Copy To Output Directory
  4. .edmx (Entity Data Model) which contains:
    • SSDL (Storage Schema Definition Language)
    • CSDL (Conceptual Schema Definition Language)
    • MSL (Mapping Specification Language)
  5. One-to-one, one-to-many, many-to-one mappings between tables and classes
  6. Supports inheritence:
    • TPH (Table Per Hierarchy)
    • TPT (Table Per Type)
    • TPC (Table Per Concrete Class)
  7. Supports complex types
  8. Code-first, Model-first, Storage-first approaches
  9. Application-centric view of a database
  10. Created by SQL Server team
  11. Future of Microsoft Data APIs

See also:

Ryszard Dżegan
  • 24,366
  • 6
  • 38
  • 56
  • 7
    This is the most current and detailed answer. – ErTR Mar 16 '16 at 01:36
  • 3
    Doesn't Entity Framework *use* LINQ to SQL when, say, you're writing a `dbSet.Where()...ToList()` ? I think it's misleading to have Entity Framework opposed from LINQ to SQL. – Don Cheadle Jun 07 '16 at 19:13
  • 5
    @mmcrae EF doesn't *use* L2S, both are linq-providers to underlying databases. If you interpret it as Linq-to-a-database, similar to linq-to-objects and linq-to-xml, then yes, both are similar in linq-to-a-database. But no, EF doesn't use L2S (or vice versa). Two completely separated tools. – Maarten Jun 14 '16 at 12:06
  • 5
    "Recommended for all new projects except ... small ones" **I disagree.** Code First is an extremely quick way to hit the ground running with small projects. Other than that, great update to this question. – DrewJordan Jun 21 '16 at 15:12
  • 2
    How to define that an project is "small" or "big" ? – Luke Jul 15 '20 at 11:53

My experience with Entity Framework has been less than stellar. First, you have to inherit from the EF base classes, so say good bye to POCOs. Your design will have to be around the EF. With LinqtoSQL I could use my existing business objects. Additionally, there is no lazy loading, you have to implement that yourself. There are some work arounds out there to use POCOs and lazy loading, but they exist IMHO because EF isn't ready yet. I plan to come back to it after 4.0

  • 1,220
  • 1
  • 11
  • 15
  • 8
    Lack of POCO support is the number one reason I have been choosing LINQ to SQL over the Entity Framework. I may revisit EF when they incorporate it in the next version, as they are promising to. There are some additional projects out there that do POCOs for EF, but not cleanly enough. – Joseph Ferris Mar 14 '09 at 17:30
  • 29
    In case someone (like me) doesn't know what POCO stands for: [Plain Old CLR Object](http://en.wikipedia.org/wiki/Plain_Old_CLR_Object "Wikipedia - Plain Old CLR Object") – CBono Sep 24 '10 at 15:16
  • 5
    I really don't see what the big fuss about not supporting POCOs is...it's one more level of abstraction guys. Create a factory, injecting the data repository and construct your POCOs there. It's probably a good idea anyway. – EightyOne Unite Oct 12 '10 at 14:42
  • 4
    I hear POCO is possible in EF 4 – PositiveGuy Dec 30 '10 at 05:24
  • 1
    Also I still have no idea of a good example of a POCO object. The Wiki page is useless in terms of describing in actual terms and examples wtf POCO is in actual usage in a real app...no examples means no help to me. – PositiveGuy Dec 30 '10 at 05:26
  • 9
    POCO support is available these days and inheritance is no longer a requirement for entity classes @CoffeeAddict POCO is just a simple object with no reliance on a specific framework and is a major part of modern entity framework patterns – Chris McGrath May 09 '12 at 13:51

I found a very good answer here which explains when to use what in simple words:

The basic rule of thumb for which framework to use is how to plan on editing your data in your presentation layer.

  • Linq-To-Sql - use this framework if you plan on editing a one-to-one relationship of your data in your presentation layer. Meaning you don't plan on combining data from more than one table in any one view or page.

  • Entity Framework - use this framework if you plan on combining data from more than one table in your view or page. To make this clearer, the above terms are specific to data that will be manipulated in your view or page, not just displayed. This is important to understand.

With the Entity Framework you are able to "merge" tabled data together to present to the presentation layer in an editable form, and then when that form is submitted, EF will know how to update ALL the data from the various tables.

There are probably more accurate reasons to choose EF over L2S, but this would probably be the easiest one to understand. L2S does not have the capability to merge data for view presentation.

  • 1
  • 1
  • 353,942
  • 115
  • 666
  • 851

My impression is that your database is pretty enourmous or very badly designed if Linq2Sql does not fit your needs. I have around 10 websites both larger and smaller all using Linq2Sql. I have looked and Entity framework many times but I cannot find a good reason for using it over Linq2Sql. That said I try to use my databases as model so I already have a 1 to 1 mapping between model and database.

At my current job we have a database with 200+ tables. An old database with lots of bad solutions so there I could see the benefit of Entity Framework over Linq2Sql but still I would prefer to redesign the database since the database is the engine of the application and if the database is badly designed and slow then my application will also be slow. Using Entity framework on such a database seems like a quickfix to disguise the bad model but it could never disguise the bad performance you get from such a database.

  • 9,497
  • 4
  • 54
  • 72
  • 2
    Your missing the point -- even with small databases, you may want something different than a 1:1 relationship between database tables and code/domain objects. Just depends on how much abstraction you want in the bus/domain objects. – alchemical Feb 11 '10 at 22:52
  • 18
    I have realized that :) Today I like to handcode my business entities. I still use Linq2sql but only inside my repositories where I get data using Linq2sql and the convert the linq2sql entities into my custom business entities. Maybe a bit more work than using a or-mapper but still I like to keep my business layer free of any OR-mapper specific code. – terjetyl Feb 12 '10 at 10:07
LINQ to SQL Entity Framework
It only works with SQL Server database It can work with various databases like Oracle, DB2, MySQL, SQL Server, etc.
It generates .dbml to maintain the relation It generates a .edmx file initially. The relation is maintained using 3 different files; .csdl, .msl and .ssdl
It has not to support for complex types It has support for complex types
It cannot generate database from model It can generate database from model
It allows only one-to-one mapping between the entity classes and the relational tables/views It allows one-to-one, one-to-many, many-to-many mappings between the entity classes and relational tables/views
It allows you to query data using DataContext It allows you to query data using EntitySQL, ObjectContext, DbContext
It can be used for rapid application development only with SQL Server It can be used for rapid application development with RDBMS like SQL Server, Oracle, PostgreSQL, etc.
  • 8,194
  • 13
  • 74
  • 92
  • 2
    Also, Linq to SQL can populate a DB from the model classes just fine. Not sure if it can also generate the DB itself, but generating the schema and tables fall within Linq to SQL's capabilities. – Tom Lint Jul 01 '16 at 12:25
  • 2
    Thanks for the answer, i think the one can use `sqlmetal.exe` https://learn.microsoft.com/en-us/dotnet/framework/tools/sqlmetal-exe-code-generation-tool to generate code/mapping from the database when using `Linq to SQL` – Vinod Srivastav Apr 19 '19 at 12:11

The answers here have covered many of the differences between Linq2Sql and EF, but there's a key point which has not been given much attention: Linq2Sql only supports SQL Server whereas EF has providers for the following RDBMS's:

Provided by Microsoft:

  • ADO.NET drivers for SQL Server, OBDC and OLE DB

Via third party providers:

  • MySQL
  • Oracle
  • DB2
  • VistaDB
  • SQLite
  • PostgreSQL
  • Informix
  • U2
  • Sybase
  • Synergex
  • Firebird
  • Npgsql

to name a few.

This makes EF a powerful programming abstraction over your relational data store, meaning developers have a consistent programming model to work with regardless of the underlying data store. This could be very useful in situations where you are developing a product that you want to ensure will interoperate with a wide range of common RDBMS's.

Another situation where that abstraction is useful is where you are part of a development team that works with a number of different customers, or different business units within an organisation, and you want to improve developer productivity by reducing the number of RDBMS's they have to become familiar with in order to support a range of different applications on top of different RDBMS's.

  • 9,014
  • 5
  • 45
  • 57

I found that I couldn't use multiple databases within the same database model when using EF. But in linq2sql I could just by prefixing the schema names with database names.

This was one of the reasons I originally began working with linq2sql. I do not know if EF has yet allowed this functionality, but I remember reading that it was intended for it not to allow this.

  • 2,539
  • 4
  • 23
  • 35

If your database is straightforward and simple, LINQ to SQL will do. If you need logical/abstracted entities on top of your tables, then go for Entity Framework.

  • 2,893
  • 2
  • 18
  • 12
  • 4
    Entity Framework allows for a layer of abstraction of top of the database. The problem with many OR Mappers today (in my opinion) is that they provide a 1 to 1 mapping between tables and classes. The database model doesn't always reflect the way that we think about it in terms of a business model. – senfo Oct 02 '08 at 00:35
  • Ran out of space. Anyhow, based on what I said above, I'd argue that your answer isn't complete. – senfo Oct 02 '08 at 00:36
  • 7
    I think this is really bad advice. L2S is good *regardless* of the simplicity or complexity of your database. The real trap is not having a proper separation of concerns. If you try to merge your business layer and your data access layer, and use your Linqed up objects for everything, then you'll find L2S limiting. But that's a problem with an overly simplistic and monolithic design. L2S makes a great DAL, and if you consider querying and persistence a separate concern from your business rules, you'll save yourself lots of trouble in lots of areas in the long run. – mattmc3 Jul 27 '10 at 23:29
  • 1
    this tells me nothing. What is simple in your terms? – PositiveGuy Dec 30 '10 at 05:27
  • 1
    and what do you mean as an example for a need of "logical/abstracted". Yes I know what abstraction is but an example in your context please... to explain to me exactly what you're saying...describe it, don't just give me general slang...that's all relative to the speaker saying those words so I have no clue what YOU mean by this. – PositiveGuy Dec 30 '10 at 05:28

Neither yet supports the unique SQL 2008 datatypes. The difference from my perspective is that Entity still has a chance to construct a model around my geographic datatype in some future release, and Linq to SQL, being abandoned, never will.

Wonder what's up with nHibernate, or OpenAccess...

John Dunagan
  • 1,445
  • 3
  • 18
  • 30
  • 4
    SQL Server 2008 Spatial datatypes (Open Geospatial Consortium OGS) supported as of Entity Framework 5. Other providers (Devart for Oracle) also supported. See http://msdn.microsoft.com/en-us/data/dn194325 . – subsci Sep 11 '13 at 07:20

I am working for customer that has a big project that is using Linq-to-SQL. When the project started it was the obvious choice, because Entity Framework was lacking some major features at that time and performance of Linq-to-SQL was much better.

Now EF has evolved and Linq-to-SQL is lacking async support, which is great for highly scalable services. We have 100+ requests per second sometimes and despite we have optimized our databases, most queries still take several milliseconds to complete. Because of the synchronous database calls, the thread is blocked and not available for other requests.

We are thinking to switch to Entity Framework, solely for this feature. It's a shame that Microsoft didn't implement async support into Linq-to-SQL (or open-sourced it, so the community could do it).

Addendum December 2018: Microsoft is moving towards .NET Core and Linq-2-SQL isn't support on .NET Core, so you need to move to EF to make sure you can migrate to EF.Core in the future.

There are also some other options to consider, such as LLBLGen. It's a mature ORM solution that exists already a long time and has been proven more future-proof then the MS data solutions (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

Ramon de Klein
  • 5,172
  • 2
  • 41
  • 64

I think if you need to develop something quick with no Strange things in the middle, and you need the facility to have entities representing your tables:

Linq2Sql can be a good allied, using it with LinQ unleashes a great developing timing.

  • 9,370
  • 6
  • 33
  • 48
  • 5,509
  • 7
  • 39
  • 47
  • 5
    "no Strange things in the middle", ok what do YOU mean by this. Example of a "strange thing in the middle" – PositiveGuy Dec 30 '10 at 05:29
  • 1
    It would be nice to edit or delete this answer, it's no longer useful for modern development and can get people on the wrong track. – Giulio Caccin Sep 29 '19 at 19:26


It is provider it supports SQL Server only. It's a mapping technology to map SQL Server database tables to .NET objects. Is Microsoft's first attempt at an ORM - Object-Relational Mapper.


Is the same idea, but using Entity Framework in the background, as the ORM - again from Microsoft, It supporting multiple database main advantage of entity framework is developer can work on any database no need to learn syntax to perform any operation on different different databases

According to my personal experience Ef is better (if you have no idea about SQL) performance in LINQ is little bit faster as compare to EF reason LINQ language written in lambda.

Umang Patwa
  • 2,795
  • 3
  • 32
  • 41

Here's some metrics guys... (QUANTIFYING THINGS!!!!)

I took this query where I was using Entity Framework

var result = (from metattachType in _dbContext.METATTACH_TYPE
                join lineItemMetattachType in _dbContext.LINE_ITEM_METATTACH_TYPE on metattachType.ID equals lineItemMetattachType.METATTACH_TYPE_ID
                where (lineItemMetattachType.LINE_ITEM_ID == lineItemId && lineItemMetattachType.IS_DELETED == false
                && metattachType.IS_DELETED == false)
                select new MetattachTypeDto()
                    Id = metattachType.ID,
                    Name = metattachType.NAME

and changed it into this where I'm using the repository pattern Linq

            return await _attachmentTypeRepository.GetAll().Where(x => !x.IsDeleted)
                .Join(_lineItemAttachmentTypeRepository.GetAll().Where(x => x.LineItemId == lineItemId && !x.IsDeleted),
                attachmentType => attachmentType.Id,
                lineItemAttachmentType => lineItemAttachmentType.MetattachTypeId,
                (attachmentType, lineItemAttachmentType) => new AttachmentTypeDto
                    Id = attachmentType.Id,
                    Name = attachmentType.Name


            return (from attachmentType in _attachmentTypeRepository.GetAll()
                    join lineItemAttachmentType in _lineItemAttachmentTypeRepository.GetAll() on attachmentType.Id equals lineItemAttachmentType.MetattachTypeId
                    where (lineItemAttachmentType.LineItemId == lineItemId && !lineItemAttachmentType.IsDeleted && !attachmentType.IsDeleted)
                    select new AttachmentTypeDto()
                        Id = attachmentType.Id,
                        Name = attachmentType.Name

Also, please know that Linq-to-Sql is 14x faster than Linq...

enter image description here

Robert Green MBA
  • 1,834
  • 1
  • 22
  • 45
  • Metrics based on two different queries (yes!), also not knowing anything about generated SQL and cold/warm start conditions, are utterly meaningless. – Gert Arnold Aug 13 '22 at 09:17