标签: data-access-layer

我有一个问题,我觉得我没有找到一个满意的答案,或者我没有找到正确的地方.

我们的系统最初是使用.NET 1.1构建的(但是项目现在都支持3.5),并且所有实体都使用存储过程和具有标准ExecuteReader,ExecutreNonQuery类型方法的"SQLHelper"持久保存到数据库.

所以通常情况下我们将拥有我们的实体,例如User和Role,我们将有另一个名为UserIO的类,它使用以下方法将这些对象持久化到数据库:

 static UserIO.SaveUser(User user)

单独的IO文件的原因是为了使IO与实体分开,但是仅仅调用它会更令人满意吗？:

User.Save()

也许我错了,但是让这些"IO"文件遍布整个地方感觉不对.所以我正在考虑寻找持久性的其他选择,我想知道哪里是最好的起点.我过去曾使用过数据集,但有一些混合经验,特别是它们的表现.我知道LINQ现在已经存在但是我听说我不应该使用LINO我应该使用ADO.NET实体框架但是其他人告诉我实体框架不太正确我应该等待C#4.0.如果是这种情况,并且C#4.0即将到来,我应该继续使用我的"IO"文件方法,并在C#4.0最终发布时从实体框架开始.或者是否可以使用更优雅的类结构,例如使用Partial Classes？

我应该说,我不是要完全取代已经存在的数据访问,我更关心我正在创建的新实体.

如果这个问题有点普遍,我很抱歉,但是我没有很多人来反复这种想法.

我有一个关于Dapper的基本逻辑问题.

在尝试做最好的设计实践时,Dapper是否模糊了DAL和BLL之间的界限？许多建议是DAL应该对BLL一无所知,并且DAL应该只返回B​​LL应该转换为某些有用对象的一些blob数据.

我想在这里得到一些专家对Dapper适合的意见.

这是一个伟大的项目,并且运作良好,但它似乎与BLL紧密结合.我个人并不反对这种方法,但是想知道1)是否有更好的方法可以解开Dapper和BLL,或2)如果它不是真正的问题,因为我们不打算离开MS SQL.

谢谢.

编辑:回应马克的评论:

Dapper是一个很棒的产品,这不是对它的任何影响......我的意思是,当你执行一个查询时,它通常会返回一个特定类型的集合.

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

在这种情况下,查询将返回Dog的集合.

如果Dapper部署在DAL层中,则必须具有对BLL层的引用,以便了解它将返回的对象类型.

许多建议是DAL永远不应该知道关于BLL的任何信息.我只是试图确定部署Dapper和保持良好的N层设计结构的最佳实践.

我知道它有点主观,但如果它足以支持Stack Overflow,那么你们都必须找到在设计良好的环境中部署它的最佳实践方法.

编辑:注意到由于HTML符号,查询示例中未显示"Dog"的类型.

再次编辑以响应Hogan的评论:我的问题的核心与上面的代码行将在DAL中的想法更相关.为清楚起见,我们可以假设我们有一个DAL和BLL作为单独的类项目的解决方案.现在,当这行代码进入DAL项目时,DAL必须引用BLL来获取"Dog"对象.这种交叉依赖性可以吗？或者只是最常用的Dapper？或者这是一种不好的做法,而不是使用Dapper的最佳方式？我知道很多'纯粹主义者'会说DAL不应该知道关于BLL的任何事情......依赖于上面一行中的"Dog"对象会违反这个原则.但是,上面的行似乎是Dapper最常见的示例用法.

我使用过Jarek Kowalski制作的" EF Provider Wrappers ".它工作正常,但我注意到"限制和免责声明"部分,其中说:

除了示例代码中包含的内容之外,提供程序尚未经过广泛测试,因此您应自行承担使用它们的风险.

与任何其他样品,微软不提供任何形式的支持它,但如果你发现错误或有功能建议,请使用此博客的联系表格,让我了解他们.

我在这里有点困惑,微软是否真的希望开发人员在生产网站上使用EnityFramework而没有任何官方支持(或建议)进行二级缓存？

我目前正在开发一个ASP.NET MVC 5项目,我正在努力改进项目的架构; 让人们在将来尽可能干净,轻松地工作.

对于初学者,我已将我的EntityFramework模型(包括IdentityUser和AccountViewModel)移动到同一解决方案中的类库项目.目前主要的MVC项目引用了这一点.

但是,我现在正在考虑创建一个新的数据访问层项目,该项目将保存DbContext(或DbContexts,如果我决定使用多个DbContexts)以及数据访问层.这样做的最佳方法是什么？

此DAL项目将引用Model项目,主MVC项目将仅引用DAL项目.

看完这篇文章后!我想知道在使用EntityFramework时确实存储库模式确实已经过时了.

所以我的两个主要问题是:

1)什么是将DAL拉入单独项目的最佳方式

2)使用EF访问数据库内容的最佳方式是什么

我有一个使用数据库(MongoDB)来存储信息的应用程序.在过去,我使用了一个充满静态方法的类来保存和检索数据,但我已经意识到这不是面向对象的,也不是未来的证据.

虽然我不太可能改变数据库,但我宁愿把一些东西与Mongo联系起来.我还希望能够使用从数据库刷新缓存对象的选项来缓存结果,但这不是必需的,可以在其他地方完成.

我已经查看了数据访问对象,但它们似乎没有很好地定义,我找不到任何好的实现示例(使用Java或类似的语言).我还有很多一个关闭案例,例如找到用于完成制表符的用户名,这些用户名似乎不太合适,并且会使DAO变大和膨胀.

是否有任何设计模式可以帮助获取和保存对象而不会过于特定于数据库？良好的实现示例将是有帮助的(最好是在Java中).

有此DAL/BLL设计建议为ASP.NET(2.0)应用由微软.我知道一些替代方案,我在这里已经阅读了相关问题.但是我想知道这个提议的解决方案现在是否值得实施,你知道的是否有一个特定的缺点？

我想开发DAL/BLL组件以供公司内部使用,从各种应用程序和脚本访问客户和员工数据等.然而,在我开始构建这些东西之前,我想确保这个解决方案是"好的".例如,BLL传递数据表而不是封装任何东西,您没有包含逻辑的隔离业务对象.它基本上只是一个愚蠢的层,可以简化CRUD操作并允许控件的数据绑定.

在这个领域有经验的人能否指出我对这种方法的赞成和反对意见？

我目前有一个应用程序,它包括:用户界面(网页)BLL(管理器和域对象)DAL(我的每个域对象的DataAccess类).

我在UI中使用以下内容来搜索域对象.

protect sub Button1_Click()
{
    IBook book = BookManager.GetBook(txtID.Text);
}

这是我的BLL

public class BookManager 
{
    public static IBook GetBook(string bookId)
    {
        return BookDB.GetBook(bookId);
    }
}

public class Book : IBook
{
    private int? _id
    private string _name;
    private string _genre;

    public string Name
    {
        get { return _name; }
        private set 
        {
            if (string.IsNullOrEmpty(value))
                throw new Exception("Invalid Name");
            _name = value;
        }
    }

    public string Genre
    {
        get { return _serial; }
        private set 
        {
            if (string.IsNullOrEmpty(value))
                throw new …

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

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

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

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

谢谢!

与我的另一个问题有点相关应该从数据访问层或接口返回原始的Hibernate注释POJO吗？,我在创建很好的分离层方面很有经验,但没有使用Hibernate或J2EE/JPA.我一直在查看文档和教程,并对如何以优雅的方式使用EntityManger感到困惑,因为它似乎负责两个事务(我想在我的服务层执行)和持久性方法(我想要的)保持在数据访问层).我应该在服务层创建它并将其注入数据访问层,还是有更好的方法？下面的伪java大致显示了我正在考虑做的事情.

编辑:我的下面的伪代码主要取自hibernate JPA教程,并针对图层分离进行了修改,并未反映出该产品是在EJB容器(Glassfish)中运行的.在您的答案中,请提供在Glassfish中运行的代码或同等代码的最佳实践和代码示例.

MyService
{

  setup()
  {
       EntityManagerFactory entityManagerFactory = Persistence.createEntityManagerFactory( "Something" ); //is the String you pass in important?
       entityManager = entityManagerFactory.createEntityManager();
  }

  myServiceMethod()
   {
   entityManager.getTransaction().begin();
   MyDao.setEntityManager(entityManagerFactory); 
   MyDao.doSomething();
   MyDao.doSomethingElse();
   entityManager.getTransaction().commit();
   entityManager.close();
   }
 }

MyDao
{
   doSomething()
    {
     entityManager.persist(...); //etc 
    }

}

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

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可以自动生成存储库中方法的查询.在我的例子中,方法在存储库和服务中重复,所以请解释什么/为什么需要更改？