加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程开发 > asp.Net > 正文

asp.net – LINQ to SQL Web应用程序最佳实践

发布时间:2020-12-15 23:41:12 所属栏目:asp.Net 来源:网络整理
导读:在我构建Web应用程序的经验中,我一直使用n层的方法.从数据库获取数据并填充对象的DAL,以及从DAL获取对象的BLL,并执行其上所需的业务逻辑,以及从BLL获取其显示数据的网站. 我最近开始学习LINQ,大多数示例都显示了Web应用程序代码隐藏的查询(可能我只看过过简
在我构建Web应用程序的经验中,我一直使用n层的方法.从数据库获取数据并填充对象的DAL,以及从DAL获取对象的BLL,并执行其上所需的业务逻辑,以及从BLL获取其显示数据的网站.
我最近开始学习LINQ,大多数示例都显示了Web应用程序代码隐藏的查询(可能我只看过过简化的例子).在n层架构中,这一直被视为一个大的不.
我不确定如何构建一个新的Web应用程序.我一直在使用VS2008中的Server Explorer和dbml设计器创建dbml和对象关系.如果dbml将被视为DAL层,如果网站应该调用BLL中的方法,然后执行LINQ查询等,似乎有点不清楚.
什么是一般架构最佳实践或使用LINQ to SQL创建Web应用程序解决方案?

解决方法

我恐怕你确实看到过分简化的例子. LINQ to SQL(System.Data.Linq)是你的DAL层. L2S生成的类是您的域(但不要与 Domain-Driven Design混淆).除此之外,您还可以编写业务层.

我总是尝试防止将LINQ to SQL DataContext泄漏到表示层(您的Web应用程序)中.所以它不应该能够创建或提交DataContext.您也不应该返回IQueryable< T>对象到表示层. IMO的业务层应该完全控制DataContext(工作单位)的生命周期以及SQL查询的形状.

但是,有几种口味.有些人冒充放松这些限制.其他人甚至更进一步.这取决于你自己的口味和应用程序的大小.应用程序越大,添加抽象层就越有道理.

当不允许IQueryable和其他数据相关的东西离开业务层时,您最终会遇到一些有趣的挑战.例如,表示层必须指示业务层如何对结果进行排序.虽然您可以让表示层对结果进行排序,但这意味着您必须从表单层的数据库和页面获取所有数据,导致性能非常差的系统.这个问题有几种解决方案.在所有情况下,您都需要通知业务层如何为您排序结果.在搜索LINQ dynamic sort时,SO可以找到解决方案.我自己写了这样一个解决方案,here.

不允许IQueryable离开你的BL的另一个挑战将是域对象经常不会离开你的BL.大多数LINQ to SQL域对象将包含延迟加载的属性(例如,到其他域对象的集合).但是,当DataContext控制业务层时,在将结果返回到表示层之前,将会被处理.当演示文稿比访问延迟加载的属性时,会发生异常,因为DataContext已被处理.当您将DataContext处理在业务层中时,此行为当然是“按设计”.允许表示层获取延迟加载属性意味着BL将丢失对发送到数据库的查询的控制,从而失去对性能的控制.

要解决此问题,您应该将数据传输对象(DTO)从BL返回到表示层. DTO将只包含数据,没有内部的DataContext,并且没有延迟加载的属性. DTO可以根据实际的要求进行特殊格式化. DTO当然会导致编码开销本身,所以您的系统的大小和性能需求必须证明它.为了使自己更容易,我倾向于在DTO上放置静态投影方法.虽然这不符合separation of concerns原则,但我认为这是一个非常实用的解决方案.在这个客户端看例子:

public class CustomerDTO
{
    public int CustomerId { get; set; }
    public string Name { get; set; }
    // City is flatterned from Address.City.
    public string City { get; set; }

    internal static IQueryable<CustomerDTO> AsDTO(IQueryable<Customer> customers)
    {
        return
            from customer in customers
            select new CustomerDTO()
            {
                CustomerId = customer.Id,Name = customer.Name,City = customer.Address.City
            };
    }
}

该DTO定义了内部AsDTO方法,该方法能够将Customer域对象的集合转换为CustomerDTO DTO的集合.这使得将域对象转换为DTO变得更加容易.以这种BL方法为例:

public static CustomerDTO[] GetCustomersByCountry(string country)
{
    using (var db = ContextFactory.CreateContext())
    {
        IQueryable<Customer> customers =
            (from customer in db.Customers
            where customer.Address.Country == country
            orderby customer.Name,customer.Id);

        return CustomerDTO.AsDTO(customers).ToArray();
    }
}

这种方法的好处是,当您查看SQL查询时,您将看到只有客户ID,名称和地址表的城市将从数据库中检索.这是因为AsDTO方法将一个IQueryable转换为另一个,允许LINQ to SQL在数据库中执行总体操作.

我希望这能给出一些你能做什么的想法.当然,这是我对这个问题的看法,以及我在我的情况下发现的实际情况.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读