Questions tagged «entity-framework»

我正在使用以下技术环境启动一个项目：.Net 4.0，Entity Framework 4.0，带有MVVM体系结构的 WPF 我在网上看到了很多例子，有些书就是关于这种环境的。在某些示例中，作者有以下想法： Viemodel将具有Model类的实例（实体框架实体，例如Person） 将WPF视图控件绑定到Model的属性 虽然有些作者这样做： Viemodel将公开模型的所有属性。 将WPF视图控件绑定到ViewModel的属性，而不是直接绑定到模型。 那么，让视图绑定模型的属性而不是让视图模型公开自己的属性是一个好主意吗？还是更优选？

21 .net  entity-framework  mvvm 

当前，我们处于选择使用现成的对象关系映射器或滚动自己的关系的情况下 我们有一个遗留应用程序（ASP.NET + SQL Server），其中数据层和业务层不幸地混在一起。该系统在数据访问方面并不是特别复杂。它从一大组（35-40）相互关联的表中读取数据，在内存中进行处理，然后以摘要格式将其保存回其他表中。现在，我们有机会进行一些重构，并且正在寻找可用于分离和正确构建数据访问的候选技术。 无论我们决定采用哪种技术，我们都希望： 在我们的域模型中具有持久性忽略的POCO对象 有一个抽象层，使我们可以根据模拟的基础数据源对域模型对象进行单元测试 显然，在模式和框架等方面已经有很多东西。 我个人正在推动将EF与ADO.NET单元可测试存储库生成器/ POCO实体生成器结合使用。它满足了我们的所有要求，可以轻松地捆绑在Repo / UnitOfWork模式中，并且我们的数据库结构相当成熟（已经进行了重构），因此我们不会每天对模型进行更改。 但是，小组中的其他人则建议完全从头开始设计/发布我们自己的DAL。（自定义DataMappers，DataContext，存储库，无处不在的接口，过分依赖以创建具体对象，自定义LINQ到底层查询翻译，自定义缓存实现，自定义FetchPlan实现...），该列表不胜枚举，直言不讳我是疯子。 引发的一些争论是“至少我们将控制自己的代码”或“哦，我在先前的项目中使用过L2S / EF，这无非是头疼”。（尽管我以前在生产中都使用过，发现任何问题很少而且相差不大，而且很容易处理） 因此，您在超级经验丰富的开发人员/架构师中是否有任何智慧的言语可能会帮助我将这个产品从我看来将是一场彻底的灾难中解脱出来。我忍不住想，通过规避EF问题而获得的任何利益，都将因尝试重新发明轮子而同样迅速地丧失。

20 design-patterns  database-development  entity-framework  nhibernate 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 8年前关闭。 ...还是事情变得越来越复杂？ 在我看来，这些天您需要了解很多知识，才能“正确”开发MS Web应用程序。在糟糕的过去，我们并没有更好的了解，我们有了数据库表，ASP.NET，ADO.NET，并且您使用相对简单的概念构建了一个Web应用程序。 如今，似乎有很多框架可以“帮助”您“正确”地完成工作，但是我不认为这会使事情变得更容易和更好。我有这种感觉，我会成为少数，但是还有其他人认为事情有点发疯了吗？

17 wcf  linq  mvc  entity-framework 

我一直在阅读Entity Framework，尤其是EF 4.1，并点击此链接（http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx）及其有关代码优先的指南。 我觉得它很整洁，但是我想知道，Code First是否应该只是快速开发的解决方案，而您无需进行太多计划就可以直接投入使用，或者它实际上打算用于大规模应用程序？

16 entity-framework  codefirst 

我打算将新的Web应用程序推送到Azure Web App Service（以前的Azure网站）。我想利用部署插槽来测试我的部署，然后再将其投入生产。只要不需要更改数据库架构就可以了。但是，如果发生模式更改，则不能在同一数据库版本上运行两个软件版本。由于我使用的是EF迁移，因此将其推入暂存插槽将立即导致数据库更新到最新版本。 所以我的问题是，当需要进行数据库迁移时，是否会使用部署槽？ 对于大型SaaS提供商，该如何做。他们是否正在使用新版本立即执行数据库迁移？这肯定会导致一些停机时间。 我只能想到解决这个问题的相当复杂的方法，有没有简单的方法？

16 entity-framework  deployment  migration  azure  continuous-delivery 

最近，我在工作中与一些同事进行了讨论，因为他们说最好在.DLL中加密一个字符串连接。我说过为什么不使用加密的web.config中定义的字符串连接？一样，更好，因为实体框架（例如，在应用程序的Web配置中查找连接的名称），现在，我想从安全角度了解哪种更好，什么是最佳实践？

14 web-development  c#  asp.net  security  entity-framework 

我一直在尝试创建一个网站，该网站将MVC和JSON用于我的表示层，以及用于数据模型/数据库的Entity框架。我的问题与将模型对象序列化为JSON有关。 我正在使用代码优先方法创建数据库。在执行代码优先方法时，一对多关系（父/子）要求子对父有引用。（示例代码是我的错字，但您会看到图片） class parent { public List<child> Children{get;set;} public int Id{get;set;} } class child { public int ParentId{get;set;} [ForeignKey("ParentId")] public parent MyParent{get;set;} public string name{get;set;} } 通过JsonResult返回“父”对象时，由于“子”具有父类的属性，因此引发循环引用错误。 我已经尝试了ScriptIgnore属性，但是无法查看子对象。在某些时候，我将需要在父子视图中显示信息。 我试图为没有循环引用的父级和子级创建基类。不幸的是，当我尝试发送baseParent和baseChild时，它们被JSON分析器读取为它们的派生类（我很确定此概念正在使我逃避）。 Base.baseParent basep = (Base.baseParent)parent; return Json(basep, JsonRequestBehavior.AllowGet); 我想出的一个解决方案是创建“查看”模型。我创建数据库模型的简单版本，其中不包含对父类的引用。这些视图模型每个都有返回数据库版本的方法和一个将数据库模型作为参数的构造函数（viewmodel.name = databasemodel.name）。尽管此方法有效，但似乎是强制的。 注意：我在这里发布是因为我认为这值得讨论。我可以利用其他设计模式来解决此问题，也可以像在模型上使用其他属性一样简单。在搜索中，我没有找到克服此问题的好方法。 我的最终目标是拥有一个很好的MVC应用程序，该应用程序充分利用JSON与服务器进行通信并显示数据。同时跨层维护一致的模型（或尽我所能）。

13 asp.net-mvc  entity-framework  orm  json 

我当前正在设计一个使用实体框架5（.net 4）作为其数据访问策略的n层解决方案，但是我担心如何合并依赖项注入以使其可测试/灵活。 我当前的解决方案布局如下（我的解决方案称为Alcatraz）： Alcatraz.WebUI：一个asp.net Webform项目（前端用户界面）引用项目Alcatraz.Business和Alcatraz.Data.Models。 Alcatraz.Business：一个类库项目，包含业务逻辑，引用项目Alcatraz.Data.Access，Alcatraz.Data.Models Alcatraz.Data.Access：一个类库项目，包含AlcatrazModel.edmx和AlcatrazEntitiesDbContext，引用项目Alcatraz.Data.Models。 Alcatraz.Data.Models：一个类库项目，包含Alcatraz模型的POCO，无引用。 我对这个解决方案如何工作的愿景是，Web-ui将实例化业务库中的存储库，该存储库将具有（通过构造函数）连接字符串（而不是AlcatrazEntities实例）的依赖项。Web用户界面会知道数据库连接字符串，但不知道它是一个实体框架连接字符串。 在业务项目中： public class InmateRepository : IInmateRepository { private string _connectionString; public InmateRepository(string connectionString) { if (connectionString == null) { throw new ArgumentNullException("connectionString"); } EntityConnectionStringBuilder connectionBuilder = new EntityConnectionStringBuilder(); connectionBuilder.Metadata = "res://*/AlcatrazModel.csdl|res://*/AlcatrazModel.ssdl|res://*/AlcatrazModel.msl"; connectionBuilder.Provider = "System.Data.SqlClient"; connectionBuilder.ProviderConnectionString = connectionString; _connectionString = connectionBuilder.ToString(); } …

12 c#  .net  dependency-injection  entity-framework  n-tier 

我正在尝试与Entity Framework一起工作，但遇到了有关层分离的问题。 我通常使用UI-> BLL-> DAL方法，我想知道如何在这里使用EF。 我的DAL通常是这样的 GetPerson(id) { // some sql return new Person(...) } BLL： GetPerson(id) { Return personDL.GetPerson(id) } 用户界面： Person p = personBL.GetPerson(id) 现在的问题是：由于EF创建了我的模型和DAL，将EF包装在我自己的DAL中是一个好主意还是只是浪费时间？ 如果不需要包装EF，我仍然可以将Model.esmx放置在其自己的类库中，还是将其放置在BLL中并在其中工作是可以的吗？ 我真的看不出将EF包装在我自己的DAL中的原因，但是我想知道其他人在做什么。 因此，除了上述内容之外，我将省略DAL并执行以下操作： BLL： GetPerson(id) { using (TestEntities context = new TestEntities()) { var result = from p in context.Persons.Where(p => p.Id = …

12 c#  entity-framework  layers 

我最近阅读了很多关于将存储库模式与功能强大的ORM（例如Entity Framework）一起使用的争论，因为它结合了类似存储库的功能以及工作单元功能。 另一个反对在单元测试之类的情况下使用该模式的论点是，存储库模式是一种泄漏抽象，因为更通用的实现利用了IQueryable。 反对使用存储库模式的论点对我来说很有意义，但是建议的替代抽象方法通常更令人困惑，并且看起来像问题一样矫kill过正。 吉米·鲍嘉（Jimmy Bogards）的解决方案似乎既要吹散抽象，又要介绍自己的体系结构。 https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/ 另一个不必要的存储库示例....但是使用我的体系结构！ http://blog.gauffin.org/2012/10/22/griffin-decoupled-the-queries/ 另一个... http://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework 我还没有找到一种明显的替代或替代方法，而该替代方法本身并不具有更多的体系结构，因此可以替代“过于复杂”的存储库模式。

12 domain-driven-design  entity-framework  orm  nhibernate  repository-pattern 

我研究的许多DDD教程都涵盖了理论。它们都有基本的代码示例（Pluralsight和类似代码）。 在网络上，也有人尝试创建涵盖EF的DDD的教程。如果您只是简短地学习它们-您很快就会发现它们彼此之间有很大的不同。有些人建议保持应用程序最小化，并避免在EF之上引入其他层（例如，存储库），其他人则决定生成额外的层，甚至通过注入DbContext聚合根甚至违反SRP 。 如果要提出基于意见的问题，我深表歉意，但是... 在实践中，实体框架是功能最强大且使用最广泛的ORM之一。不幸的是，您不会找到涵盖DDD的综合课程。 重要方面： 实体框架可立即使用UoW和存储库（DbSet） 使用EF，您的模型具有导航属性 与EF所有的车型都始终可用的关闭DbContext（它们被表示为DbSet） 陷阱： 您不能保证子模型仅受“聚合根”影响-您的模型具有导航属性，可以修改它们并调用dbContext.SaveChanges() 与DbContext您可以访问每一个模型，从而规避聚合根 您可以通过将ModelBuilderin 标记为字段来通过in OnModelCreating方法来限制对根对象的子对象的访问-我仍然不认为这是进行DDD的正确方法，而且很难评估这种情况将来可能导致什么样的冒险（非常怀疑） 冲突： 如果没有实现返回聚合的另一层存储库，我们甚至无法部分解决上述陷阱 通过实现额外的存储库层，我们将忽略EF的内置功能（每个DbSet都已经是仓库）并且使应用程序过于复杂 我的结论是： 请原谅我的无知，但基于以上信息-要么是实体框架 不足以用于域驱动设计，或者域驱动设计是不完善且过时的方法。 我怀疑每种方法都有其优点，但是我现在已经完全迷失了，对如何将EF与DDD调和一无所知。 如果我错了-请问至少有人能详细介绍一下如何使用EF进行DDD的简单说明（甚至提供不错的代码示例）吗？

12 c#  design-patterns  object-oriented-design  domain-driven-design  entity-framework 

在我们的业务逻辑中，我们有时会定义一些类似于以下内容的方法： User.ResetCourse(Course courseToReset) 问题在于用户和课程都是实体框架代理对象。这意味着当我们在“用户”或“课程”上命中导航属性时，可能会严重打击数据库，因为这些对象不可查询，因此可以正常地遍历它们。 为了解决这个问题，我们将签名更改为： User.ResetCourse(MyDBContext db, Course courseToReset) 这意味着我们可以直接查询数据库以有效地进行所需的更改，但是将Database上下文传递给业务对象似乎太错误了。 后来我们向用户迁移了服务层，这意味着我们拥有以下内容： CourseService.ResetForUser(Course courseToReset, User forUser) 该服务引用了创建时注入的DBContext，但是现在我们的业务对象只是没有行为的数据包（例如，Anemic Domain Model）。 我们如何避免这种情况？

11 c#  entity-framework  domain-model  business-logic 

我有一个ProjectName.Core库，其中包含我的所有业务逻辑以及我的实体及其行为。当前与Entity Framework或任何其他DAL没有任何关系，因为我喜欢将这些内容分开。实体框架配置（使用Fluent API）位于ProjectName.Infrastructure项目中，以便将实体推入EF。基本上，我会朝着类似洋葱的架构的方向发展。 但是，将ASP.NET Identity框架添加到组合中时，我必须使我的ApplicationUser实体从IdentityUser该类继承，但是我的ApplicationUser类与其他实体有关系。在继承时，IdentityUser我在实体项目中引入了对Entity Framework的引用，这是我不想这样做的地方。将ApplicationUser类从实体项目中拉出并放入Infrastructure项目中（因为它使用的是基于Entity Framework的身份系统）将导致循环引用，因此也不可行。 有没有什么办法可以解决，所以除了不使用ASP.NET Identity之外，我还可以保持两层之间的清晰分隔？

11 asp.net-mvc  entity-framework  identity 

从使用Linq2Sql进行的一个项目中，我怀疑下一个（更大）的项目可能会将我推入Entity Framework的怀抱。我已经对该主题进行了一些阅读，但是我没有找到一个连贯的故事，关于如何/应该/可能将SQL Server数据工具和实体框架一起使用。 它们是完全分开构想的，并且一起使用会产生错误的结果吗？ 它们是否完全正交，我错过了要点？ 我认为我可能同时想要这两个原因： SSDT非常适合“编译”（检查）且易于版本控制的sql和schema 但是，SSDT的“迁移/更新”故事（在我看来）并不令人信服：“更新任何内容”对于架构都可以，但是（AFAIK）绝不可能对数据起作用。 另一方面，我还没有尝试过EF迁移来了解它是否存在类似的问题，但是Up / Down位看起来非常方便。

11 entity-framework 

原来的样子 多年以来，我一直在组织软件解决方案，例如： 数据访问层（DAL），用于抽象访问数据的业务 业务逻辑层（BLL），用于将业务规则应用于数据集，处理身份验证等。 实用程序（Util）只是我逐渐建立的常用实用程序方法的库。 表示层当然可以是Web，桌面，移动等。 现在的样子 在过去的四年左右的时间里，我一直在使用Microsoft的Entity Framework（我主要是.NET开发人员），并且由于Entity Framework已经完成了DAL工作，因此我发现拥有DAL变得越来越麻烦。我的DAL曾经做过的工作：它抽象了针对数据库运行CRUD的业务。 因此，我通常以一个DAL结束，该DAL具有如下方法的集合： public static IQueryable<SomeObject> GetObjects(){ var db = new myDatabaseContext(); return db.SomeObjectTable; } 然后，在BLL中，该方法将按如下方式使用： public static List<SomeObject> GetMyObjects(int myId){ return DAL.GetObjects.Where(ob => op.accountId == myId).ToList(); } 当然，这是一个简单的示例，因为BLL通常会应用多行逻辑，但是在这样有限的范围内维护DAL似乎有点多余。 放弃DAL并像这样简单地编写我的BLL方法会不会更好： public static List<SomeObject> GetMyObjects(int myId){ var db = new myDatabaseContext(); return db.SomeObjectTable.Where(ob …

11 architecture  data-structures  entity-framework  separation-of-concerns