标签: data-access-layer

您对数据访问层有何建议？使用ORM,如Entity Framework和Hibernate OR Code Generators,如Subsonic,.netTiers,T4等？

DAO模式和Data Mapper模式之间有区别吗？DAO只是做Data Mapper的吗？

我正面临着关于如何设计DAL的设计问题.众所周知,在最基本的定义中,DAL意味着负责与某些数据存储库通信的层(当然我不是在讨论存储库模式),通常是数据库.现在这就是捕获的地方.我们的一些业务对象必须从数据库中获取数据,而有些则从其他来源(即Web服务)获取数据.我们团队中的一些成员建议BO应该足够聪明,知道是否要调用DAL(只知道与数据库通信)或调用所需的Web服务.其他人认为这可能不是一个最佳解决方案,这表明一切都应该通过DAL,在那里它将包含让我们说的适配器,或者其他任何数据检索方法.

您如何构建具有此类数据访问需求的系统？从长远来看,任何建议的解决方案是否足够好(第二个可能需要更多时间来开发),还是我们需要采取完全不同的方法？也许有一种适合这种问题的设计模式......

谢谢,Avi Shilon

在域层或数据访问层？

我正在创建一个新的Web应用程序,它将使用一堆数据访问对象(DAO)类对数据进行CRUD操作.我知道当我有使用我的DAO类的外部用户/应用程序时,我应该编写java接口.但是如果没有这样的需求你认为我还应该编写接口吗？我将使用spring将DAO类注入Spring Controller(我正在使用Spring MVC)类.

我对BLL和DAL的关系有点困惑.BLL是否应通过依赖注入封装DAL？或者BLL是否只对域对象和DAL单独保存/更新？

例如,想象(在典型的MVC应用程序中)取消订单功能,要求您更新订单并更新库存.以下是我的行动的样子吗？

public ActionResult CancelOrder (Guid orderId) {
    Order order = orderRepository.Get(orderId);
    StockItem stockItem = stockRepository.Get(order.StockItemId);

    _orderService.CancelOrder(order, stockItem);
    orderRepository.Update(order);
    orderRepository.Update(stock);
    Return View();
}

或者它应该更像下面这样？

public ActionResult CancelOrder (Guid orderId) {
    _orderService.CancelOrder(orderId);
    Return View();
}

(within OrderService)
public void CancelOrder(Guid orderId) {
    Order order = orderRepository.Get(orderId);
    StockItem stockItem = stockRepository.Get(order.StockItemId);

    order.Cancelled = true;
    stockItem.AmountInStock = stockItem.AmountInStock + order.Amount;
    orderRepository.Update(order);
    orderRepository.Update(stock);
}

使用此选项,BLL将处理所有内容,包括数据访问.将注入存储库以避免紧密耦合.然后,任何实体检索将采用_orderService.GetOrder(orderId);相似的形式直接进入存储库.

请原谅示例的粗糙,因为我没有太多时间.我写的任何东西都是有意义的,还是我在荒野中？

的DbContext在EF Code first器具的工作单位和存储库模式为 MSDN网站上说:

DbContext实例表示工作单元和存储库模式的组合,以便它可以用于从数据库进行查询并将更改组合在一起,然后将更改作为一个单元写回到存储中.DbContext在概念上类似于ObjectContext.

这是否意味着使用另一个UoW和Repository抽象(例如IRepository和IUnitOfWor),超过DbContext是错误的？

换句话说,在DbContext上使用另一个抽象层是否会为我们的代码添加任何其他值？

技术独立DAL(我们的域将取决于IRepository和IUnitofWork而不是DbContext)等值

我对我正在使用的架构有疑问.

我们有一个后端restful服务,一个数据层(由python eve和一个restful服务实现)和数据库.数据(访问)层本身是一个独立的restful api.

在我们的后端服务应用程序中,我们有一个定制的python eve存储库,它可以调用数据(访问)层,然后数据层将查询来自数据库的调用所要求的内容.

让它分离的原因之一是,我们希望将数据逻辑(查询逻辑)与业务逻辑(后端服务)隔离开来.

成本是显而易见的,另一层,每个查询的另一轮I/O.

任何有建筑经验的人都可以告诉我这个单独的数据访问层是否是一个好的做法,为什么？

我目前陷入了这个解决方案的设计.

数据层设计包括以下内容:

• 食谱(父级高级对象)
  • 语言详细信息(名称,语言描述)(很多)
    • 标题(很多)
    • 步骤(很多)
      • 配料(很多)
      • 数量(很多)
      • 程序(很多)
    • 笔记(很多)

我遇到的挑战是如何创建一个数据访问设计,当从WCF SaveRecipe(配方)方法填充对象时,该设计将添加/删除数据库中的子对象？

这一切都源于管理层要求我们在我们的应用程序中添加通信层,现在我们的UI耦合到我们的业务层,而BL直接耦合到DAL,我们基本上需要在BL和DAL之间注入WCF .

我在这篇帖子中读过,使用L2S对WCF来说不是一个好主意,但由于设计不是新的,我们必须使用这种类型的方法,然后一旦我们可以重构大量的方法就离开它UI工作.

我只是想知道从课堂上找回读者的正确方法？

我的代码可以使用,但我不确定这是否正确.

也.我无法关闭我的类方法中的连接,仍然可以从我的ascx页面访问它,是

那好吗？

//在我的班级中,我有以下方法来返回记录/阅读器 - 在这种情况下它是一条记录.

public SqlDataReader GetPost()
    {
        SqlConnection conn = new SqlConnection(connectionString);
        SqlCommand cmd = new SqlCommand("con_spPost", conn);
        cmd.CommandType = CommandType.StoredProcedure;
        cmd.Parameters.AddWithValue("@blogid", blogid);
        try
        {
            conn.Open();
            return cmd.ExecuteReader();
        }
        finally
        {
          //  conn.Close();
        }
    }

//然后我在ascx页面中调用GetPost方法,如下所示:

protected void Page_Load(object sender, EventArgs e)
{

    //instantiate our class
    MyClass DB = new MyClass();

    //pass in the id of the post we want to view
    DB.PostID = Int32.Parse(Request.QueryString["p"]);

    ///call our GetPost method
    SqlDataReader reader = DB.GetPost();

   //output the result …