Tag: data access layer

在我们的解决方案中将entity framework放在何处？

好的，我们有一个包含以下项目的解决方案： 商业逻辑 实体 数据访问 公用事业 unit testing 用户界面 它是一个非常大的企业级应用程序。 我的问题是，我们在哪里放置entity framework？ 一方面，EF看起来像数据访问技术，应该进入DataAccess项目。 但另一方面，它会生成自己的实体，这些实体应放在我们已经很大的实体项目中。 哪个项目更适合entity framework？ 是否有可能将实体与EF中的持久性逻辑分开？

每组操作的可重用ObjectContext或新ObjectContext？

我是entity framework的新手，我刚开始在空闲时间玩它。 我遇到的一个主要问题是如何处理ObjectContexts。 通常优先/推荐这些： 这个 public class DataAccess{ MyDbContext m_Context; public DataAccess(){ m_Context = new MyDbContext(); } public IEnumerable GetSomeItems(){ return m_Context.SomeItems; } public void DeleteSomeItem(SomeItem item){ m_Context.DeleteObject(item); m_Context.SaveChanges(); } } 或这个？ public class DataAccess{ public DataAccess(){ } public IEnumerable GetSomeItems(){ MyDbContext context = new DbContext(); return context.SomeItems; } public void DeleteSomeItem(SomeItem item){ MyDbContext context […]

entity framework中多个“包含”的最佳实践是什么？

假设我们在数据模型中有四个实体：Categories，Books，Authors和BookPages。 还假设Categories-Books，Books-Authors和Books-BookPages关系是一对多的。 如果从数据库中检索类别实体实例 – 包括“Books”，“Books.BookPages”和“Books.Authors” – 这将成为一个严重的性能问题。 而且，不包括它们将导致“对象引用未设置为对象的实例”exception。 使用多个Include方法调用的最佳做法是什么？ 写一个方法GetCategoryById并包含所有项目（性能问题） 写一个方法GetCategoryById并发送一个包含的关系列表（可能，但似乎还不够优雅） 编写方法，如GetCategoryByIdWithBooks，GetCategoryByIdWithBooksAndBooksPages和GetCategoryByIdWithBooksAndAuthors（不实用） 编辑 ：通过第二个选项我的意思是这样的： public static Category GetCategoryById(ModelEntities db, int categoryId, params string[] includeFields) { var categories = db.Categories; foreach (string includeField in includeFields) { categories = categories.Include(includeField); } return categories.SingleOrDefault(i => i.CategoryId == categoryId); } 在调用时我们需要这样的代码： Category theCategory1 = CategoryHelper.GetCategoryById(db, 5, “Books”); Category theCategory2 […]

使用BLL函数而不参考我的API中的DAL

我有3个项目（C＃）API，BLL和DAL。 DAL引用DAL，API引用BLL。 在我的API中我需要使用所有的CRUD函数，但我不能使用我的BLL中的函数，因为VS说“类型”blabla“是在未引用的程序集中定义的。您需要添加引用（DAL） ）“但我不想在API项目中引用DAL。 有没有办法在不使用我的DAL项目的情况下完成它？

BLL，DAL，OBJ和3层架构

我的问题是关于3层架构。 我的项目简要类似于下面的内容，但令我恼火的是在我在数据库中插入新列后，我必须更新除BLL之外的所有字段。 在表示层中，我创建了一个OBJ以及DAL内部的DAL，还有一个SQL查询。 我必须手动更新所有这些字段。 如果我以“正常”的方式进行，我将所有这些放在表示层中并在一个地方进行更新。 我是否正确应用这种3层架构，使用这种分层架构有哪些优势？ 我的第二个问题是： 在DAL内部，我通过_view收集数据。 我想知道，我应该为每个视图编写另一个BOboj吗？我已经有一个BOboj类但它不包含所有字段。 在插入数据时，我必须使用我的BOboj，但是，当列出数据时，我正在使用视图，在这种情况下，我应该为每个视图或另一个东西创建另一个BOboj_view类吗？ 什么是easyies方式呢？ 例如; 我有20个视图和40个类映射到sql server上的每个表，我的视图收集数据不同的表（这意味着不同的对象）。我应该再创建20个类，除了代表视图的40个？ OBJ class BOboj { private int _PId; private string _Name; ……. ……. } DAL BOboj_DAL { public bool Add(BOboj obj) { using (SqlConnection con = Connect.connect) { string sql = “insert into Persons (Id,Name, ……. ……. } BBL BOboj_BLL { ……. […]

存储库层是否应该返回数据传输对象（DTO）？

我有一个存储库层负责我的数据访问，由服务层调用。 服务层返回序列化并通过线路发送的DTO。 通常，服务只是访问存储库并返回存储库返回的内容。 但为了使其工作，存储库必须返回该DTO的实例。 否则，您首先必须将存储库返回的数据层对象映射到服务层中的DTO并返回该对象。 这看起来很浪费。 最重要的是，如果DTO的创建发生在服务层中，那么在一个存储库调用之前可能已经完成的事情以及因此一个数据库查询现在必须在服务层中的多个存储库调用中发生以“组合”最后的DTO。 当然，除非我在数据和服务层之间创建一个可以包含这样一个组合对象的传输对象。 然后必须将其映射到DTO。 为了纯洁，这似乎是浪费。 但是，让存储库层返回仅通过线路发送的对象也是错误的。