Questions tagged «architectural-patterns»

我一直在阅读/观看Robert C. Martin的很多内容。我碰到他说，由于固态硬盘，SQL是不必要的。当我搜索其他资源以进行备份时，我会收到大量随机文章，描述硬盘驱动器和固态驱动器之间的SQL性能差异（相关但与我要研究的内容无关）。 最终，我不明白他在试图达到什么目的。他是说用No-SQL技术取代SQL吗？他是说在文件系统中的文件中存储数据吗？还是他只是希望人们因为SQLi攻击而停止使用SQL /关系数据库？我担心我错过了他想表达的观点。 我将在此处提供一些链接，以便您可以直接从他的心中读懂： 鲍比表 清洁建筑讲座 首先，他指出应该从系统中完全删除SQL。 解决方案。唯一的解决方案。是从系统中完全消除SQL。如果没有SQL引擎，那么就不会有SQLi攻击。 并且尽管他谈论使用API​​替换SQL，但我不认为他的意思是将SQL放在API后面，因为前面的引用以及他在本文前面所说的。 框架无法解决问题； ... 旁注：在说SQL时，我很确定Robert意味着大多数关系数据库。也许不是全部，而是大多数。无论如何，大多数人还是使用SQL。所以... 如果不使用SQL来持久化数据，那么我们应该使用什么呢？ 在回答之前，我还应该注意。罗伯特（Robert）强调，固态驱动器应该改变我们用来持久化数据的工具。SørenD.Ptæus的回答指出了这一点。 我还必须回应“但是数据完整性”组。经过进一步研究，罗伯特说我们应该使用像datomic这样的事务数据库。然后，CRUD变成CR（创建和读取），并且SQL事务完全消失。数据完整性当然很重要。 我找不到涵盖所有这些的问题。我想我正在寻找符合罗伯特指南的替代方案。Datomic是一个，但是是吗？还有哪些其他选项与这些准则匹配？它们在固态驱动器上是否更好地工作？

45 architecture  enterprise-architecture  architectural-patterns  plugin-architecture 

的清洁体系结构建议让交互器调用实际执行的演示者（其被注入时，DIP以下）的处理响应/显示的用例。但是，我看到人们实现了这种体系结构，从交互器返回输出数据，然后让控制器（在适配器层中）决定如何处理它。除了没有明确定义交互器的输入和输出端口之外，第二种解决方案是否将应用程序职责泄漏到应用程序层之外？ 输入和输出端口 考虑到Clean Architecture的定义，尤其是描述控制器，用例交互器和演示者之间关系的小流程图，我不确定我是否正确理解“用例输出端口”应该是什么。 像六边形体系结构一样，干净的体系结构区分主要端口（方法）和次要端口（由适配器实现的接口）。按照通信流程，我希望“用例输入端口”是主要端口（因此只是一个方法），而“用例输出端口”是要实现的接口，也许是使用实际适配器的构造函数参数，以便交互器可以使用它。 代码示例 举例来说，这可能是控制器代码： Presenter presenter = new Presenter(); Repository repository = new Repository(); UseCase useCase = new UseCase(presenter, repository); useCase->doSomething(); 演示者界面： // Use Case Output Port interface Presenter { public void present(Data data); } 最后，交互器本身： class UseCase { private Repository repository; private Presenter presenter; public UseCase(Repository …

42 architecture  architectural-patterns  onion-architecture 

我的情况如下。 我正在设计一个系统，该系统旨在从各种类型的传感器接收数据，然后进行转换并将其持久化，以供以后的各种前端和分析服务使用。 我正在尝试将每个服务设计为尽可能独立，但是遇到了一些麻烦。团队已决定要使用的DTO。面向外部的服务（传感器数据接收者）将以自己独特的方式接收数据，然后将其转换为JSON对象（DTO）并将其发送给Message Broker。消息的使用者将确切地知道如何读取传感器数据消息。 问题是我在几个不同的服务中使用了相同的DTO。必须在多个位置实施更新。显然，我们的设计方式使得此处的DTO中有一些多余或缺失的字段，并且在更新服务之前不会有太大的问题，但这仍然困扰着我，并使我感到自己犯错误。它很容易变成头痛。 我在设计系统时会出错吗？如果没有，那么有什么解决办法，或者至少可以缓解我的担心？

33 architecture  microservices  architectural-patterns  dto  pubsub 

我怎样才能知道我的软件有太多的抽象和太多的设计模式，或者反过来，我怎么知道它是否应该有更多的抽象呢？ 与我合作的开发人员在这些方面的编程方式有所不同。 有些人确实提取每个小功能，尽可能使用设计模式，并不惜一切代价避免冗余。 其他人，包括我在内，都试图更加务实，并编写出并非完全适合每种设计模式的代码，但由于应用了较少的抽象，因此其理解速度更快。 我知道这是一个权衡。我如何知道何时将足够的抽象放入项目中，又如何知道需要更多抽象呢？ 例如，当使用Memcache编写通用缓存层时。难道我们真的需要Memcache，MemcacheAdapter，MemcacheInterface，AbstractCache，CacheFactory，CacheConnector，...，或者这是更易于维护和使用仍然只有一半时，好的代码这些类的？ 在Twitter中找到了这个： （https://twitter.com/rawkode/status/875318003306565633）

29 design-patterns  architecture  clean-code  abstraction  architectural-patterns 

我正在构建一个API，一个上传文件的函数。如果文件上传正确，此函数将不返回任何内容/无效，并且在出现问题时将引发异常。 为什么要例外而不是错误？因为在异常中，我可以指定失败的原因（无连接，文件名丢失，密码错误，文件描述丢失等）。我想构建一个自定义异常（带有一些枚举来帮助API用户处理所有错误）。 这是一个好习惯还是返回一个对象（内部包含布尔值，可选错误消息和错误枚举）更好？

22 java  api-design  exceptions  functions  architectural-patterns 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 异步非阻塞事件驱动的编程似乎风行一时。我对这一切意味着什么有基本的概念理解。但是，我不确定的是我的代码何时何地可以从异步中受益，或者如何使阻塞式IO成为非阻塞式。我敢肯定，我可以简单地使用一个库来做到这一点，但是我对更深入的概念以及自己实现它的各种方式更感兴趣。 是否有任何全面/权威书籍或其他资源在这个问题上（如GoF的设计模式，或K＆R为C，TLDP对于像bash）的？ （注意：我不确定这在功能上是否与我学习事件驱动编程有关的问题相同）

21 design-patterns  learning  books  architectural-patterns  asynchronous-programming 

按照定义，实体组件系统体系结构是否面向对象？对我来说，这似乎更具程序性或功能性。我的观点是，它不会阻止您以OO语言实现它，但是以坚定的OO方式实现它并不是惯用的。 似乎ECS会将数据（E＆C）与行为（S）分开。作为证据： 这个想法是在实体中没有嵌入任何游戏方法。 和： 该组件包含用于特定目的的最少数据集 系统是具有一组具有特定组件的实体的单一目的功能 我认为这不是面向对象的，因为面向对象的很大一部分是将您的数据和行为结合在一起。 作为证据： 相反，面向对象的方法鼓励程序员将数据放置在程序其余部分无法直接访问的位置。而是通过调用专门编写的函数（通常称为方法）来访问数据，这些函数与数据捆绑在一起。 另一方面，ECS似乎只不过是将数据与行为分开。

20 design-patterns  object-oriented  functional-programming  architectural-patterns  entity-component-system 

我最近一直在研究CQRS / MediatR。但是，我越深入，就越不喜欢它。也许我误会了一些东西。 因此，它声称可以将您的控制器简化为 public async Task<ActionResult> Edit(Edit.Query query) { var model = await _mediator.SendAsync(query); return View(model); } 完全符合瘦控制器指南。但是，它忽略了一些非常重要的细节-错误处理。 让我们看一下Login新MVC项目中的默认操作 public async Task<IActionResult> Login(LoginViewModel model, string returnUrl = null) { ViewData["ReturnUrl"] = returnUrl; if (ModelState.IsValid) { // This doesn't count login failures towards account lockout // To enable password failures …

17 c#  asp.net  architectural-patterns 

标题说“ Circular Dependency”，但这不是正确的措辞，因为对我来说，设计似乎很牢固。 但是，请考虑以下情形，其中蓝色部分由外部合作伙伴提供，橙色是我自己的实现。还假设有多个ConcreteMain，但我要使用一个特定的。（实际上，每个类都有更多的依赖关系，但是我在这里尝试简化它） 我想通过Depency Injection（Unity）实例化所有这些，但是我显然可以StackOverflowException在以下代码上找到，因为Runner试图实例化ConcreteMain，而ConcreteMain需要一个Runner。 IUnityContainer ioc = new UnityContainer(); ioc.RegisterType<IMain, ConcreteMain>() .RegisterType<IMainCallback, Runner>(); var runner = ioc.Resolve<Runner>(); 我该如何避免呢？有什么方法可以构造它，以便可以与DI一起使用？我现在正在执行的方案是手动设置所有内容，但这ConcreteMain在实例化它的类中具有硬性依赖。这就是我要避免的事情（在配置中使用Unity注册）。 下面的所有源代码（非常简化的示例！）； public class Program { public static void Main(string[] args) { IUnityContainer ioc = new UnityContainer(); ioc.RegisterType<IMain, ConcreteMain>() .RegisterType<IMainCallback, Runner>(); var runner = ioc.Resolve<Runner>(); Console.WriteLine("invoking runner..."); runner.DoSomethingAwesome(); Console.ReadLine(); } } …

15 architecture  dependency-injection  architectural-patterns 

我是一个自学成才的新手程序员，因此，如果我不喜欢程序员的话，我深表歉意。 我正在从事一个项目，在该项目中，我将向开发人员提供不断更新的数据，这些开发人员实际上将创建一种工具，用于根据对数据的查询生成报告。 似乎每个参与人员都认为他们需要将数据值（不是模式，而是域/值本身）硬编码到报告生成程序中。 例如，假设我们正在报告人员情况；该报告将分为几类，每个部门都有一个标题，然后在每个部门标题下将是职务的子标题，然后在每个子标题下将是雇员列表。开发人员希望对部门和职位进行硬编码。另一方面，我认为他们可以/将在运行时查询这些事情，对它们进行排序，并根据存在的值动态生成报告标题。 由于潜在价值的列表将随着时间而变化（例如，将创建/重命名部门，将添加新的职务），因此需要不断更新代码。在我看来，我们可以跳过代码维护步骤，并动态组织报告。 由于我不是开发人员，所以我想知道自己缺少什么。将值硬编码到这样的工具中可能有什么优势？这通常是程序的设计方式吗？

13 design  architecture  architectural-patterns  dynamic-data 

看起来像我的发布-订阅和Reactor模式非常相似。它们有何不同？ 在这两种模式中，消息都间接传递给订户（反应堆模式中的侦听器）。 我觉得观察者模式也非常类似于其他两个模式。 这些模式之间的主要区别是什么？

11 architectural-patterns 

考虑两个类Dog并且Cat都符合Animal协议（就Swift编程语言而言。这将是Java / C＃中的接口）。 我们有一个屏幕，显示猫和狗的混合列表。有一个Interactor类处理幕后逻辑。 现在，我们要向用户显示删除猫的确认警报。但是，需要立即删除狗而不发出任何警报。有条件的方法如下所示： func tryToDeleteModel(model: Animal) { if let model = model as? Cat { tellSceneToShowConfirmationAlert() } else if let model = model as? Dog { deleteModel(model: model) } } 该代码如何重构？闻起来很香

10 architecture  refactoring  software  architectural-patterns  polymorphism 

所以我有一个工厂，可以创建不同类的对象。可能的类都是从抽象祖先派生的。工厂具有配置文件（JSON语法），并根据用户的配置来决定要创建哪个类。 为此，工厂使用boost :: property_tree进行JSON解析。他遍历ptree并决定要创建哪个具体对象。 但是，产品对象具有许多字段（属性）。根据具体的类，对象具有大约5-10个属性，将来可能会更多。 因此，我不确定对象的构造函数应如何。我可以想到两种解决方案： 1）产品的构造函数希望将每个属性作为参数，因此构造函数最终将带有10个以上的参数。这将是丑陋的，并导致较长的，不可读的代码行。但是，优点是工厂可以解析JSON并使用正确的参数调用构造函数。产品类不需要知道由于JSON配置而已创建。不需要知道完全涉及JSON或配置。 2）产品的构造函数只需要一个参数property_tree对象。然后，它可以解析所需的信息。如果配置中的信息丢失或超出范围，则每个产品类别都可以正确响应。工厂不需要知道几种产品需要哪些参数。如果配置错误，工厂也不需要知道如何应对。而且构造函数的接口是统一的，很小的。但是，缺点是，该产品需要从JSON中提取所需的信息，因此，它知道如何构造它。 我倾向于选择解决方案2）。但是，我不确定这是否是好的工厂模式。让产品知道它是用JSON配置创建的，这感觉有点不对劲。另一方面，可以很简单地介绍新产品。 有什么意见吗？

10 design-patterns  object-oriented  c++  architectural-patterns  factory-method 

我正在为即将设计的功能寻找图案或体系结构指导。基本上，这是一个具有多个导出目标的导出功能，我正在寻找一种方法，使之足够通用，以便在插入新的导出目标时不需要进行很多核心更改。通过导出目​​标，我只是指的是不同类型的输出，无论是PDF，PowerPoint演示文稿，Word文档，RSS等。我都有一组基本数据，以JSON和XML表示。此数据用于构造图像（使用任何数量或导出类型（例如，PNG，JPG，GIF等），图形，文本表示形式，表格等。 我正在尝试找到一种将所有渲染和布局抽象为某种渲染或布局引擎的方法，该引擎可以处理其他导出目标的添加。任何有关如何解决此问题的帮助/建议/资源将不胜感激。提前致谢。 对于我要实现的目标的图形表示。

10 patterns-and-practices  architectural-patterns 

当前，我们有一个经典的n层应用程序：DB / Web服务/前端。它具有其他组件，但这是基本布局。 我们要提高应用程序可用性的原因有3个： 我们的主机有时会遇到中断（就像它们一样），我们希望最大程度地减少对客户的影响，因此，例如，如果数据中心A关闭，他们将打开数据中心B。 升级版本时，我们会关闭站点进行维护，通常需要几个小时（迁移脚本等）。我们希望用户进行更无缝的过渡，并尽可能减少停机时间（他们在升级服务器A时使用服务器B）。 可选地，我们的客户遍布世界各地，尽管他们之间的联系不畅，我们希望他们能获得最好的体验（与印度开发人员合作的任何人都应该明白我的意思）。理想情况下，我们希望能够在其办公室中插入服务器（或使用其所在城市附近的数据中心），并将其无缝集成到我们的体系结构中。 我们远程不需要99％的可用性，甚至不需要95％的可用性。这是一个文档管理应用程序。没人在乎。但是，由于迁移可能需要一段时间，并且世界各地都有客户，因此有时我们会阻止客户在一天的大部分时间里工作。 对于SQL部分，即使没有“适当的” DBA，我们也了解SQL的可能性：复制，镜像等。在DB端，为此很容易找到资源。还有什么更困难的了：存储会话，代码等。如果我的Web服务服务器出现故障，我的UI如何知道它必须切换？我的会话如何在服务器之间持久化？ 不幸的是，我们都没有这方面的经验，我们甚至都不知道从哪里开始。是否有最佳做法？设计模式？图书馆（应该是免费的，因为我们没有钱）？ 我们使用的是ASP.Net和SQL Server，中间是WCF Web服务。我们有很多Windows服务，但它们不是关键任务，我认为处理网站的方法将适用于这些服务。 我知道大多数云平台都为此提供了内置系统，但是由于我们的系统管理员，云托管是行不通的，他想自己管理一切而不依赖任何人。

10 architecture  architectural-patterns