Лучше всего разработайте методы для архитектуры.NET с LINQ к SQL (необходимый DAL? Мы можем действительно использовать POCOs? Шаблон разработки для принятия?)

Question

Лучше всего разработайте методы для архитектуры.NET с LINQ к SQL (необходимый DAL? Мы можем действительно использовать POCOs? Шаблон разработки для принятия?)

tasks.Add(await MyContext.SaveChangesAsync(););

должно быть без ожидания

tasks.Add(MyContext.SaveChangesAsync());

И ваш код начинает работать. (выражение await возвращает асинхронный результат, без await возвращает задание, которое будет выполнено позже) Но, как уже упоминалось, не следует выполнять SaveChangesAsync () каждый раз, когда объект добавляется в контекст, это может быть сделано для всех добавленных объектов за один раз. [ 113]

9

architecture design-patterns linq-to-sql .net c#

задан GONeale 9 April 2009 в 05:43

3 ответа

Другие вопросы по тегам:

architecture design-patterns linq-to-sql .net c#

Похожие вопросы:

score 3 · Answer 1

When I looked at Rob Connery's Storefront, it looked like he is using POCOs and Linq to SQL; However, he is doing it by translating from the Linq to SQL created entities to POCO (and back), which seems a little silly to me - Essentially we have a DAL for a DAL.

However, this appears to be the only way to use POCOs with Linq to SQL.

I would say you should use a Repository pattern, let it hide your Linq to SQL layer(or whatever you end up using for data access). That doesn't mean you can't use Linq in the other tiers, just make sure your repository returns IQueryable.

score 5 · Answer 2

Чтобы ответить на ваши вопросы:

Должен ли я выполнять LINQ to SQL непосредственно на моем сервисном / бизнес-уровне или в DAL в методе репозитория? LINQ to SQL имеет смысл только в том случае, если ваша база данных отображается 1-к-1 с вашими бизнес-объектами. В большинстве корпоративных ситуаций это не так, и Entities более уместно.

Как уже было сказано, LINQ в целом весьма уместно использовать непосредственно на вашем бизнес-уровне, поскольку поставщик LINQ (будь то LINQ to SQL или что-то еще) - это ваш DAL. Преимущество LINQ заключается в том, что он позволяет вам быть гораздо более гибким и выразительным на бизнес-уровне, чем DAL.GetBusinessEntityById (id) , но код, близкий к металлическому, который обеспечивает работу и LINQ, и традиционного кода DAL, инкапсулирован от вас, что дает тот же положительный эффект.
Верите ли вы, что мы действительно можем использовать POCO (простые старые объекты CLR), когда использовать LINQ to SQL? Без более конкретной информации о проблемах POCO, связанных с LINQ to SQL, трудно сказать.
Вы бы отбросили фасет «модели» для более крупных проектов Шаблон MVC в целом далеко более широкий, чем поверхностный взгляд на ASP.NET MVC может означать. По определению, все, что вы решите использовать для подключения к своим данным, в вашем приложении становится вашей моделью. Если для подключения к облаку данных предприятия используется WCF или MQ, пусть будет так.

score 3 · Answer 3

Whether or not you use LINQ-to-SQL, it is often cmomon to use a separate DTO object for things like WCF. I have cited a few thoughts on this subject here: Pragmatic LINQ - but for me, the biggest is: don't expose IQueryable / Expression<...> on the repository interface. If you do, your repository is no longer a black box, and cannot be tested in isolation, since it is at the whim of the caller. Likewise, you can't profile/optimise the DAL in isolation.

A bigger problem is the fact that IQueryable leaks (LOLA). For example, Entity Framework doesn't like Single(), or Take() without an explicit OrderBy() - but L2S is fine with that. L2S should be an implementation detail of the DAL - it shouldn't define the repository.

For similar reasons, I mark the L2S association properties as internal - I can use them in the DAL to create interesting queries, but...