Questions tagged «repository»

存储库为数字产品提供了一种存储机制。可以指[version-control]，例如[git]或[svn]。除非该问题本质上是通用的，否则应将特定于应用程序的标记与此标记一起使用，以标识正在使用的特定存储库管理接口。另请参见：[存储库模式]

5
人们为什么要在GitHub上分叉存储库？[关闭]
我注意到很多GitHub帐户仅具有从其他帐户派生的存储库。此外，执行此操作的人员通常不会对派生的存储库做出任何贡献。 我听说有人在收集邮票和贝壳，但是为什么有人要收集仓库呢？就我个人而言，如果我想对其进行一些更改，则只会派出一个存储库。
3
控制器调用存储库而不是服务是不好的做法吗？
控制器调用存储库而不是服务是不好的做法吗？ 解释更多： 我发现，在好的设计控制器中，可以调用服务和服务使用存储库。 但有时在控制器中，我不需要任何逻辑，只需要从db中获取并将其传递给视图即可。 而且我可以通过调用存储库来做到这一点-无需调用服务-这是不好的做法吗？
4
何时使用存储库模式
我最近读到，将存储库模式与ORM结合使用不是一种好习惯。从我的理解来看，这是因为它们在SQL数据库上提供的抽象太泄漏而无法包含在模式中。 我对此有两个问题： 如果要转出ORM，该怎么办？如果您未在存储库中包含ORM特定代码，则您的应用程序中将包含该代码。 当不使用ORM且您正在使用ADO.NET进行数据访问并自己填充对象数据时，存储库模式仍然有效吗？ 如果您使用ORM而不是存储库模式，那么将常用查询保留在哪里？将每个查询表示为一个类并具有某种查询工厂来创建实例是否明智？
2
存储库真正应该做什么？
我听说过很多存储库模式，但是我完全不了解存储库应该真正做什么。当我说“存储库应该真正做什么”时，我主要是在担心它应该提供哪些方法。例如，存储库应该真正提供CRUD方法，还是应该提供某种其他方法？ 我的意思是，存储库应包含业务逻辑，还是应仅包含与数据存储进行通信并管理要保存或加载的实体的逻辑？ 我还听说存储库是聚合的持久性单位。那怎么了 我不明白这在实践中是如何工作的。我认为我们应该只有一个IRepository包含CRUD方法的接口，然后对于任何实体，实现都将仅包含用于保存和从数据存储中检索此类的逻辑。
1
我们使用存储库模式正确吗？
我们正在使用一堆带有后缀的独立类，-repository以从数据库中检索数据。每个表都有自己的存储库。 例如，我们有一个customerrepository具有各种方法来检索客户的类，并且具有一个vacancyrepository具有各种方法来检索空缺的类。 关于这种做事方式，我有两个问题： 如何获取跨越多个表的数据？例如，我有一个屏幕，显示所有尚未创建空缺的客户。可以customerrepository从中使用方法vacancyrespository，还是两个存储库都返回结果，并且层次结构中是否有更高的类（我们将其命名为a dataservice）从两个存储库中获取结果并将它们合并为1个结果？ 这样的存储库可以处理多少逻辑？ 我认为可以在存储库中实现“ where active == true”以仅检索活动记录，还是应该由层次结构中较高的类来处理简单的逻辑（将其命名为a dataservice）？ 我现在遇到的示例是以下示例： 我们有一个问题列表，其中包含一个或多个问题。 问题可以有一个结果，该结果保存在单独的表中。 因此，当您要检索问题列表的总结果时，必须合并questionlist表，问题表和questionstatus表中的数据。 现在，我们为这些表提供3个不同的存储库。 如果我要问questionlistrepository清单12的总结果是什么，那将不得不从另外两个存储库中获取数据，因此其中有些逻辑，这是允许的吗？ 还是有questionlistdataservice哪个知道要使用哪个存储库？ 还有一件事：我们的存储库可以生成一个结果，IQueryable以便调用服务可以轻松地合并结果，但是如果不是这种情况，我认为从列表中检索所有三个表的所有内容不是一个好主意。数据库。
4
从域访问存储库
假设我们有一个任务记录系统，当记录一个任务时，用户指定一个类别，并且该任务默认为“未完成”状态。在这种情况下，假定类别和状态必须作为实体实施。通常我会这样做： 应用层： public class TaskService { //... public void Add(Guid categoryId, string description) { var category = _categoryRepository.GetById(categoryId); var status = _statusRepository.GetById(Constants.Status.OutstandingId); var task = Task.Create(category, status, description); _taskRepository.Save(task); } } 实体： public class Task { //... public static void Create(Category category, Status status, string description) { return new Task …
1
在对较早的提交进行修复时，我应该重新设置基础还是添加单独的修复提交？
软件开发中的一种常见情况是代码检查其他人的代码。执行此操作的常用工具是打开请求请求。 我的问题是，当在审查中发现问题时，是否应进行更改 分开提交（新提交） 还是应该修改现有的提交（假设没有人从您先前的提交中分支出来，因为从共享分支重写历史记录是个坏消息）。 对于第一种情况，尽管它会在提交历史记录中增加一些噪音，但是很容易跟踪增量更改。第二种选择具有相反的优点和缺点。
1
如何在CQRS + Event Sourcing架构中处理Add / Create *命令
我想使用CQRS模式和Event Sourcing来实现我的第一个应用程序。我想知道如何正确处理聚合根的创建。假设有人发送CreateItem命令。应该如何处理？事件ItemCreated应该存储在哪里？作为新项目的第一事件？还是我应该具有某种ItemList实体来聚合所有项目，并且其事件列表仅由ItemCreated事件组成？ 乌迪·达汉（ Udi Dahan）建议不要创建聚合根，而应始终使用某种获取方法。但是我如何获取新的东西，当然还没有分配任何ID。我理解背后的想法，并且认为一个新对象是其状态由零个事件组成的对象是很合理的。但是我应该如何使用呢？我的存储库中应该有一个与众不同的方法吗？getNewItem()还是让我的get(id)方法接受Optional<ItemId>？ 编辑：经过一段时间的挖掘，我发现使用actor对上述模式进行了非常有趣的实现。作者不是创建聚合，而是从某种具有新创建的UUID的存储库中检索聚合。这种方法的缺点是他允许出现临时的不一致状态。我也想知道如何delete使用这种方法来实现方法。只需将Deleted事件添加到聚合的事件列表中？
1
GitHub组织的跨多个存储库的项目？
我已经启动了一个项目，该项目至少涉及GitHub上的三个存储库。 其中一个存储库是一个通用的文档和示例转储，另外两个存储库包含两个程序的实现，这些程序构成了项目的主干。 我是否应该使用GitHub Organization处理此类配置？还是我应该将所有信息与其他十个完全不相关的存储库一起转储到我自己的帐户中？
2
.NET MVC项目体系结构/分层
在为中型MVC Web应用程序规划体系结构时，如何实现这些层尽可能地分离和易于测试？（基本上遵循最佳实践）假设我首先使用代码作为数据访问权限。 我为定义“业务逻辑”的定义以及与数据层交互的方式感到困惑。以车辆销售应用程序为例，业务逻辑是否是执行诸如计算给定车辆的税阶，比较每加仑英里数统计信息之类的任务的类？至于业务实体（例如汽车，货车，摩托车），我会将它们与DataContext班级一起放在数据层中。 还有什么会构成与业务相对的应用程序逻辑-我正在猜测会话/用户输入验证之类的东西？ 因此，例如，汽车管理员可能会返回一个操作/查看结果，其中列出了按类型和最佳mpg过滤的前十名汽车。假设我有一个ICarRepository“ carRepo”注入到我的控制器中（使用存储库模式/ DI），我从一个动作方法参数中过滤了我的汽车var cars = carRepo.getCarsByType("hatchback"); 因此，我已使用存储库将数据访问知识排除在控制器之外，现在使用域模型将业务逻辑排除在控制器之外-var result = new MpgCalculator（cars）; -假设我需要计算器类，因为它需要执行其他逻辑以计算最佳燃油效率，而不仅仅是从数据库中加载/过滤实体。因此，现在我有了一个供呈现的视图数据集，该数据集使用存储库从数据访问层检索，并且使用特定于域的对象来处理和执行与数据相关的业务相关任务。 我在这里犯错吗？我们仍然需要使用存储库模式吗？或者我可以只对接口进行编码以解耦ORM和进行测试吗？关于这个主题，因为我的具体数据访问类dbcontext在数据层中，所以接口定义是否应该进入域/业务层，这意味着如果数据访问技术发生了变化，我的其他层是否会受到影响？ 根据到目前为止的研究，我的结构如下所示： MVC Internet应用程序 ->标准Internet项目-这里的模型是ViewModels 域/业务层 ->特定于业务的类/模型，控制器可以使用这些类/模型来处理数据层中的域实体，然后再传递到相关视图 存储库抽象有必要吗？->我听到很多关于此的辩论，尤其是在使用ORM时 数据层 ->实体类（汽车，货车，摩托车），DbContext-具体数据访问技术层
2
具有存储库模式的TDD
在我的新项目中，我决定尝试使用TDD。一开始我就遇到了问题。我想在应用程序中做的第一件事就是赋予从数据源读取数据的能力。为此，我想使用存储库模式。现在： 如果测试是为了真正实现存储库接口，那么我将测试具有数据库访问权限的类，并且我知道应该避免这种情况。 如果测试不是针对存储库模式的真正实现，那么我将进行良好的测试……只是模拟。在这些单元测试中，将不会测试任何生产代码。 我从两天开始考虑这个问题，但仍然无法提出任何合理的解决方案。我该做什么？
2
要存储库还是不存储库
当我第一次了解域驱动设计时，我还被介绍到了存储库和工作单元模式，这些存储模式和工作单元曾经看起来像是那些酷炫的孩子向数据库发送SQL查询（例如穴居人）的最佳选择。我对这个话题的了解越深，我越了解到它们似乎不再是必需的了，因为EF和NHibernate之类的ORM将工作单元和存储库都实现到一个称为会话或上下文的API中。 现在我不确定该怎么办。是否存储库。我真的很理解这样的论点，即这样的泄漏抽象只会使事情复杂化，而绝对没有增加任何可以简化数据访问的内容，但是，将我的应用程序的各个方面都耦合到例如Entity Framework的感觉并不正确。通常，我遵循一些简单的准则： 域层是系统的核心，包含实体，服务，存储库... 基础结构层提供基础结构领域的域接口的实现，例如文件，数据库，协议。 应用程序层承载一个组合根，该根将所有事物连接起来并进行编排。 我的解决方案通常如下所示： Domain.Module1 Domain.Module2 IModule2Repo IModule2Service Module2 Infrastructure.Persistence Repositories EntityFrameworkRepositoryBase MyApp Boostrapper -> inject EntityFrameworkRepositoryBase into IRepository etc. 我使用a保持域层整洁，IRepository<'T>这也是一个域问题，不依赖于任何其他告诉我如何访问数据的内容。当我现在要实现IModule2Service需要数据访问的具体实现时，我将不得不注入DbContext并将其直接耦合到基础架构层。（要进入Visual Studio项目，由于循环依赖关系，最终可能会非常棘手！） 另外有什么可以到其他托管和作品fucktons？CQRS？如何抽象一个纯粹的基础架构？
2
存储库模式与DAL对象创建
据我了解，IRepository应当包含CRUD。然后，我们继承了这个IRepository在我们的其它接口，如IProduct和落实IProduct具体类ProductRepository，用类似的方法GetAllProducts()，Top5Products()。 我们也可以对n层架构进行同样的操作。像，创建DAL Class Library并在它定义一个类Product以类似的方法GetAllProducts()，Top5Products()。 在这两个DAL.Product和Repo.ProductRepository我们初始化类DB Context的Entity Framework和查询我们的相关数据。 呼叫是在两个相似Repo.ProductRepository或DAL.Product从方法BLL 鉴于这些相似之处，我的问题是Repos有什么好处？我可以使用的多层架构与做同样的轻松得多（Controller，BLL Class Library，DAL Class Library）。
3
ASP.net 5和EF7中是否不再需要存储库？
我在github上向EF团队发布了一个问题。我得到了一个答复，说最好在这里提出这个问题，所以我将其复制并粘贴到此处作为链接，以便其他人可以在GitHub上看到一些答复。 问题：我正在做一些研究，有人指出DBContext类的第24行指出 DbContext是工作单元和存储库模式的组合。 这是否意味着我们不再需要将EF抽象到存储库，然后使用and Interface将其注入Controller中？ Github上的原始帖子：https : //github.com/aspnet/EntityFramework/issues/4899 我问这个问题的原因是，我似乎进入了一个即时状态，即在存储库中添加了很多方法，例如GetById，GetByName，GetWithIncludesABC，GetWithIncludes123等。这似乎在困扰着我
3
是否存储可编辑的网站内容？
我们有一个基于Django的网站，我们希望对其内部一些内容（文本和诸如定价计划之类的业务逻辑）进行轻松地编辑，因此我们决定将其存储在代码库之外。通常原因是以下之一： 这是非技术人员想要编辑的东西。一个示例是网站的文案写作-程序员使用默认值为“ Lorem ipsum ...”的文本准备一个模板，然后将实际内容插入到数据库中。 我们希望能够快速进行更改，而无需部署新代码（我们目前每周执行两次）。一个示例是当前以不同定价级别向客户提供的功能。无需对它们进行硬编码，而是从数据库中读取它们。 所描述的解决方案是灵活的，但是出于某些原因我不喜欢它。 因为必须从数据库读取内容，所以会产生性能开销。 我们通过使用缓存方案来减轻这种情况，但这也增加了系统的复杂性。 与在生产环境上运行的方式相比，在本地运行代码的开发人员看到的系统处于截然不同的状态。自动化测试还会使系统处于不同的状态。诸如在登台服务器上测试新功能之类的情况也变得更加棘手-如果登台服务器没有数据库的最新副本，则它可能与生产意外地不同。 我们可以通过偶尔将新状态提交到存储库（例如通过添加数据迁移）来缓解这种情况，但这似乎是错误的方法。是吗？ 任何想法如何最好地解决这些问题？有没有更好的方法来处理我忽略的内容？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.