Where can I choose from using LINQ to SQL? (Excerpt)

Although Microsoft's ORM has many problems, there are already enough alternatives on the market, such as LLBLGen, nhib.pdf, and OpenAccess, many developers are forced to use Microsoft technologies because of the needs of their companies or customers. In contrast, it seems that most developers are convinced that the Entity Framework is not a feasible solution. So how should they respond?
Steel Price chooses to forget the decline of Linq to SQL and continue to use it because it can work. As for the Entity Framework, he wrote that it cannot access internal columns.

I will never use such a joint relationship, for example, "provide me with all the addresses modified by John ". This will make things worse. I cannot get the CreatedById of the Address unless I load the entire Login object and reference it like this: Address. CreatedByLogin. LoginId. This approach is too bad when you are writing and creating a query.
Is there a way to solve this problem? Of course there are, but the methods are too complicated and cumbersome. Using L2E makes 80% of my work more complicated. Only 20% of the features are complex mappings that I really need, but I can use other tools, such as LLBLGen Pro or OpenAccess, because they are easier to use.

C # MVP David Hayend speaks to the voices of most developers, that is, to make the Open Source of LINQ to SQL. He further suggested that the same ASP. net mvc approach should be adopted for the LINQ to SQL statement, originated from the Community design.

I strongly recommend that Microsoft rebuild the initial development team for LINQ To SQL, integrate them into. NET 4.0, and put them on CodePlex in an open-source manner. This has no choice. Given that LINQ To SQL is already significantly biased towards the Entity Framework, only the ADO. NET team can find the right direction for him.
I suggest the new team adopt ASP. the net mvc team works in a similar way, so that we can obtain a testable lightweight O/R er and pay attention to continuous community feedback and frequently release the CTP version.

Ian Cooper, another MVP, sees neither LINQ to SQL nor Entity Framework being completely suitable,
Another MVP, Ian Cooper, believes that both the LINQ to SQL and the Entity Framework are not fully applicable.

Simply by suppressing competitors, it is difficult to save our lack of confidence in EF (Entity Framework. We need to have a deeper understanding of the criticism, but those statements do not point out what is better than "Ef. L2s has many features that EF requires, such as domain priority support, Poco, SQL generation performance, and delayed loading. If you lack a public understanding of these advantages, doubts will inevitably continue, regardless of whether ADO. Net recognizes the positive support of LINQ to SQL.

It is not advisable to discard the LINQ to SQL directly. He suggested that Microsoft admit the mistakes that have been made and start again based on the advantages of both.

The better result should be that Microsoft announced the development of a joint successor of the LINQ to SQL and the Entity Framework. Get Feedback from the product, and then build a new one, which can be called "LINQ to relations" or "LINQ to RDBMS ". If necessary, make sure that reuse can save you money, but you need to re-plan. What I cannot imagine is that, in any case, API changes are more important than what l2s and EF developers need to face in the next iteration of your Orm.
[…]
Most people agree with Faulkner's suggestion and are trying to discard your favorite. Sometimes, the more features you invest, the more likely you will need to re-plan.
Therefore, it should be released early and frequently.

Finally, Scott Allen's problem focuses on the database.

In my opinion, the internal structure of LINQ to SQL can develop from a good foundation to a general data ing Framework, to make up for the shortcomings of the ORM-type Framework (such as Entity Framework. The framework can remove some heavy work related to object-to-object ing, or provide additional ing capabilities between different formats such as XHTML, JSON, and CSV through a provider-type architecture. Data conversion, message transmission, and data pushing are indispensable for most large applications. The framework can make these tasks easy to implement and test in a common way, this brings efficient productivity.