标签: data-access-layer

我已经阅读了关于这个主题的其他几个问题(这里,这里,这里),但还没有看到一个很好的答案.我之前已经开发了我公平的数据访问层,并且个人更喜欢使用实例类而不是静态类.但是,它更多的是个人偏好(我喜欢测试我的业务对象,这种方法可以更容易地模拟DAL).我之前使用静态类来访问数据库,但我总是觉得这种设计的适当性有点不安全(特别是在ASP.NET环境中).

任何人都可以提供一些关于这两种方法的优点/缺点,特别是在ASP.NET应用程序中使用ADO.NET提供程序(无ORM)开发数据访问类.如果您有更一般的静态与实例类技巧,请随意加入.

特别是,我担心的问题是:

1. 线程和并发
2. 可扩展性
3. 性能
4. 任何其他未知数

谢谢!

我查看了一些相关的问题,但我仍然看不到存储库和服务层之间的差异.所以考虑到这个例子,我想它应该是这样的,如果不是,请告诉我为什么？

public interface ProductRepository extends CrudRepository<Product, Long>{

    public List<Product> findByName(String name);
    public List<Product> findByPrice(Double price);
}

public interface ProductService {

    public List<Product> findAll();
    public Product findById(Long id);
    public Product save(Product product);
    public void delete(Product product);
    public List<Product> findByName(String name);
    public List<Product> findByPrice(Double price);
}

并且ProductService的实现将使用ProductRepository来实现这些方法.据我所知,从http://docs.spring.io/spring-data/jpa/docs/1.3.0.RELEASE/reference/html/jpa.repositories.html可以自动生成存储库中方法的查询.在我的例子中,方法在存储库和服务中重复,所以请解释什么/为什么需要更改？

我一直在调查用于我正在设计的基于Web的新项目的数据层,我非常希望看到将LINQ加入SQL.它显而易见的简单性,灵活性和设计器支持确实很吸引人,并且与SQL Server的隐式绑定很好.

但是,最近已经宣布LINQ to SQL现在已经退回到实体框架,因为它已被传递给ADO.NET团队(http://blogs.msdn.com/adonet/archive/2008/10 /29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx).当然,它将在未来得到支持,但它不太可能会看到更多的开发工作.

考虑到这一点,您是否会建议我将此技术用于我的项目,还是值得选择替代ORM(nHibernate？)或手动编写通用DAL？

该项目本身是基于ASP.NET和SQL Server 2005/2008的,并且可能会使用MVC,即使它仍处于测试阶段.这是一个个人项目,数据库不会过于复杂,主要用作查看.NET未来技术的原型.我将基于我从这一方面学到的东西来建立未来项目,所以我做出的选择将影响更大的解决方案.

是的,我意识到微软可能会在明天推出一种全新的数据访问技术!;)

我目前正按照ASP.NET最佳模式和实践将我的sqlite db文件存储在App_Data文件夹中.

目前我在webconfig中使用以下内容:

  <connectionStrings>
    <add name="sqlite"  
         connectionString="Data Source=|DataDirectory|MyDB; Version=3;" />
  </connectionStrings>

以及代码中的以下内容:

       public SqliteDAO(string path)
        {
            Connection = new System.Data.SQLite.SQLiteConnection(path );
        }

//...

//where path = |DataDirectory|MyDB

它导致sqlite创建一个新数据库(其中没有表),因此我的数据访问调用都没有工作,因为他们没有找到表名.如何从WebApplication代码中引用App_Data文件夹中的sqlite db文件？

谢谢!

我的工作中有一个现有的DB2数据库.(至少,我认为它是DB2.它们将它称为"iSeries",它在某些大型机硬件上看起来和感觉就像DB2.)多年来我部门的.NET开发人员只需手动编写ADO命令和查询从特定表格等获取特定数据

目前,我正在构建一些基础架构,以帮助简化内部软件的开发和支持,我想解决的一件事就是这种数据访问.我对各种ORM工具有点新意,但我熟悉LINQ语法,这就是我想要的.这就是我们现在所拥有的:

1. 已建立的DB2数据库,包含许多表.
2. 代码中没有已建立的业务对象.
3. 表与任何潜在的业务对象之间没有有用的关系.

所以我要做的是在代码和DB2数据库之间创建一个抽象层,开发人员可以基本上更加流畅有效地完成他们已经做的事情(抓取数据并填充自定义对象).也就是说,不要创建经典的ADO对象并填充DataSet,只需编写一个简单的LINQ语句,该语句返回一个匿名的IQueryable,其中包含填充自定义对象的字段.(作为一个额外的好处,我真的很喜欢编译时错误的想法,当程序员弄乱了一些东西而不是运行时错误时,就像打字输入到SQL命令字符串文字时那样.而且,甚至不让我这里开始讨论SQL注入漏洞.)

问题是,我还没有找到任何方法来实现这一目标.完全有可能我忽略了一些简单的事情,如果是这样的话,那么我欢迎在正确的方向上稍微推动一下.但是,我发现在线的所有内容都符合以下类别之一:

1. 是的,你可以这样做!您所需要的只是来自IBM的驱动程序,没有下载链接!
2. 这是一个方便的教程,用于为业务对象生成一个很好的ORM,从头开始创建数据库.(NHibernate,大多数情况下,如果我可以将它用于我正在尝试做的事情,这将非常棒.)
3. 下载一些工具并生成您的ORM.(当我尝试时,工具不支持DB2,或声称但失败.)

以前有人碰到这样的事吗？我是以完全不正确的方式接近它吗？对此事的任何建议都将不胜感激,谢谢.

编辑:我将继续前进,并为此提供赏金.我和一些人谈过,听起来"它还不能完成"仍然是回答,但如果有人解决这个问题并找到了解决方案,我很乐意听到.

更新:感谢下面的答案指向我的DB_Linq项目.实际上我没有花太多时间为它添加一些基本的DB2支持,现在我有一个经过测试和工作的LINQ to DB2提供程序!它现在非常简单,并且非常适合我们的环境,因此没有计划将其贡献给项目.但希望我能够随着时间的推移成熟我的叉子并将其发回.谢谢!

人们对我大吼大叫,我应该总是使用存储库模式,我已经做了很长一段时间......现在我想知道这个模式是否有任何合适的替代方案？

几年后我又回到了.NET开发阶段,现在看来,特别是对于LINQ,您访问数据的方式已经改变并变得更加容易.例如,在ASP.NET MVC网站中,我可以:

• 新增项目
• 添加LINQ-to-SQL类
• 将数据库表拖到LINQ-to-SQL对象关系设计器上,单击"保存"
• 通过LINQ单行访问和操作我的数据(我在这里学到:http://www.asp.net/learn/mvc/tutorial-11-cs.aspx)

这看起来很棒,但它是如何真实世界的？

• 是你在实际项目中使用的上述LINQ-to-SQL场景,还是只是一种快速的脚手架技术,即当你开始添加,删除数据库中的字段和表时会发生什么,LINQ-to-SQL类是如何做的保持同步？

我如何理解这个领域的所有新技术,例如

• Subsonic适合哪些地方？
• Astoria(ADO.NET数据服务)适合哪些地方？
• NHibernate适合哪些地方？
• 如何使用LINQ-to-SQL的其他数据库(我尝试在对象关系设计器上拖动SQLite表并获得"不支持的错误")或者仅针对SQL Server使用LINQ-to-SQL？
• LINQ-to-XML是否像LINQ-to-SQL一样工作,例如我可以将XML文件拖入设计器然后使用LINQ访问它们,还是我需要为此编写自己的代码？

• LINQ-to-Entities是否像LINQ-to-SQL一样工作,即自动生成的类,但只有更多的选项？

• 现在我们有LINQ,ADO.NET的DataTables和DataSets是一项老技术吗？LINQ-to-ADO.NET有意义吗？

• Azure在哪里适合您甚至不再拥有RDBMS的地方

• 当您的UI只是简单地与WCF交谈或与Web服务交谈时,ESB适合哪里？

现在我们有很多选择,如果您可以为项目选择任何这些技术,您会选择哪个以及为什么？

我正在使用一个分层架构,将实体框架作为我的数据层,顶部有一堆存储库,其中包含Linq-To-Entities查询.数据层是一个项目,旁边是我有一个服务层和接口,这是一个网站.

我希望我的网站负责为我的实体模型指定连接字符串.我该怎么做呢？

我使用单例方法到达我的实体存储库,该存储库位于数据层内.

谢谢

我们正处于一个包含多个子项目的长期开发项目的开端.基本上每个子项目都需要几个月的时间来开发.代码本身将分成几个C#项目,但物理数据库将由所有项目共享.

问题是可维护性.如果我们向表中添加一个列,或者将一个表拆分成两个较小的表,我们将不得不返回并修改我们的C#DAL以支持这些更改.这是不可接受的,因为我们将不断调整数据库以满足整个公司的需求,而不仅仅是单个程序的需求.不断改变旧代码将是一项无休止的任务.

我们的DB人员提出了不同的观点.我们通过存储过程完成所有CRUD,并在几个表中使用Linq来执行SELECT语句.然后,如果我们从现在起几年后重构数据库,我们可以简单地提供相同的存储过程和视图,而不必修改我们的旧代码.

我们的问题是,ORM应该用于这样的事情吗？EF似乎有点矫枉过正(可能不是).像SubSonic这样的T4模板是否适合简化(也许更快)DAL？

或者也许有人知道如何让整个过程不那么痛苦？我们宁愿不在我们的应用程序中添加另一个层,但我们也不想每次进行db更改时返回并修改代码.

编辑1:所以当我说"我真的不想添加更多图层"时.这主要是因为我们已经有几层.我们有Silverlight视图,视图模型,BLL对象(通过CSLA)然后我们有DAL,最后是SQL表格.

每比特一点,我是不成熟的,并且对ASP.NET MVC4越来越熟练.但是,我仍然没有在这个非常重要的问题上清楚地表明这一点.让我们说我有一个模型:

public class WorkPaper
{
    public int WorkPaperID { get; set; }
    public string name { get; set; }
    public string description {get ; set; }
    public bool verified {get; set;}
    public DateTime dateAdded {get; set;}

}

我使用此模型与实体框架代码第一种方法,我有以下数据库上下文:

public class NicodemeContext : DbContext
{
     public DbSet<WorkPaper> Workpapers { get; set; }
}

我不明白的是:什么是模型层以及什么是数据访问层.对我来说,WorkPaper类往往是DAL的一部分,因为我设计它并选择我的属性名称和类型(导航属性等...)以适应EF模式.但问题是,如果我是对的,我真的不知道应该把业务逻辑放在哪里.

在这种特定情况下,如果我想添加一条规则,说明如果尚未经过验证就无法发送工作文件,而另一条规则说如果超过2周之前已添加工作文件则无法提交(奇怪的规则)但那只是一个例子).我应该在哪里添加它们？我是否必须创建另一个类,但是我应该把它放在哪里以及它应该包含什么？对于我已经拥有的课程,这不是很多余吗？但另一方面,由于该类是"面向数据库",在那里添加业务规则不是很麻烦吗？

我的观点是真正理解我必须放置业务逻辑并理解DAL和模型之间的区别.我很难识别DAL和模型层,因为它们看起来与我非常相似.我想以正确的方式做事.

(基本上,我不知道在哪里用MVC编写"我的程序"!一旦我想编写我真正感兴趣的功能,我就不舒服了.我觉得我做的不对)