Questions tagged «architecture»

从我（有限地）接触函数式编程语言（例如Clojure）开始，似乎数据封装的作用不那么重要。通常，各种本机类型（例如地图或集合）是代表对象的首选数据。此外，该数据通常是不可变的。 例如，这是Clojure的成名人物里奇·希基（Rich Hickey）在接受此事采访时最著名的名言之一： Fogus：遵循了这个想法，Clojure并未对其类型进行数据隐藏封装，这一事实使某些人感到惊讶。您为什么决定放弃数据隐藏？ Hickey：让我们清楚一点，Clojure强烈强调对抽象的编程。但是在某个时候，某人将需要访问数据。而且，如果您有“私有”的概念，则需要相应的特权和信任的概念。这就增加了很多复杂性和很小的价值，在系统中产生了僵化，并常常迫使事物生活在不应有的地方。这是将简单信息放入类时发生的其他损失的补充。在某种程度上，数据是不可变的，提供访问的危害很小，除了有人可能会依赖可能发生变化的事物之外。好吧，好吧，人们在现实生活中一直如此，当事情发生变化时，他们就会适应。如果他们是理性的，他们知道，当他们基于可能会改变的事物做出决定时，将来可能需要适应。因此，这是一项风险管理决策，我认为程序员应该可以自由做出。如果人们不希望对抽象编程，也不愿意与实现细节相结合，那么他们永远都不会成为优秀的程序员。 来自面向对象的世界，这似乎使我多年来学到的一些基本原则变得复杂。其中包括信息隐藏，德米特定律和统一访问原则等。封装的共同点是使我们能够为其他人定义API，让他们知道应该和不应该接触的内容。从本质上讲，创建一个合同，允许某些代码的维护者自由地进行更改和重构，而不必担心它将如何在用户代码中引入错误（开放/封闭原则）。它还为其他程序员提供了一个干净，精心设计的界面，以使他们知道可以使用哪些工具来获取或建立该数据。 当允许直接访问数据时，该API合同被破坏，所有这些封装好处似乎都消失了。同样，严格不变的数据似乎在遍历特定于域的结构（对象，结构，记录）时，在表示状态和可以对该状态执行的操作的意义上要有用得多。 当代码库的大小变得巨大而需要定义API且许多开发人员参与处理系统的特定部分时，功能代码库如何解决似乎出现的这些问题？是否存在这种情况的示例，以说明在这些类型的代码库中如何处理此情况？

15 object-oriented  architecture  functional-programming 

我正在设计一个包含三个部分的应用程序： 监视某些事件（文件创建，外部请求等）发生的单个线程 N个工作线程通过处理它们来响应这些事件（每个工作进程处理并消耗一个事件，并且处理可能需要花费可变的时间） 一个控制器，用于管理那些线程并执行错误处理（线程重新启动，结果记录） 尽管这是非常基本的，并且不难实现，但我想知道这样做的“正确”方法是什么（在Java的这种具体情况下，但也希望有更高的抽象答案）。我想到两种策略： 观察者/可观察者：监视线程由控制器观察。在发生事件的情况下，然后会通知控制器，并可以将新任务分配给可重用的缓存线程池中的空闲线程（如果所有线程当前都忙，请等待并将任务缓存在FIFO队列中）。工作线程实现Callable并返回结果（或布尔值）成功或返回错误，在这种情况下，控制器可以决定要执行的操作（取决于发生的错误的性质）。 生产者/消费者：监视线程与控制器（事件队列）共享一个BlockingQueue，并且控制器与所有工作器（任务队列和结果队列）共享两个。在发生事件的情况下，监视线程将任务对象放入事件队列中。控制器从事件队列中获取新任务，对其进行审阅并将其放入任务队列中。每个工作人员都在等待新任务，并从任务队列中获取/使用它们（先到先服务，由队列本身进行管理），然后将结果或错误放回到结果队列中。最后，控制器可以从结果队列中检索结果，并在出现错误的情况下采取相应的步骤。 两种方法的最终结果是相似的，但是它们都有细微的差别： 使用观察者，线程的控制是直接的，每个任务都归属于特定的新生成的工作程序。创建线程的开销可能更高，但是由于缓存了线程池，因此开销并不大。另一方面，“观察者”模式被简化为单个“观察者”模式，而不是多个观察者模式，这与其设计的目的不完全相同。 队列策略似乎更容易扩展，例如，添加多个生产者而不是一个生产者很简单，不需要任何更改。不利之处在于，即使根本不做任何工作，所有线程也将无限期运行，并且错误/结果处理看起来不像第一个解决方案那样优雅。 在这种情况下最合适的方法是什么？为什么？我发现很难在线找到该问题的答案，因为大多数示例仅处理明确的案例，例如用“观察者”案例更新许多具有新值的窗口或与多个消费者和生产者进行处理。任何输入，不胜感激。

15 java  architecture  concurrency  observer-pattern  producer-consumer 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我是否可以假设大多数最终用户使用的版本都比Java 8老？由于我不想强迫人们升级以使用我的应用程序，因此我是否应该计划从一开始就使用Java 7甚至6，即使这意味着我不能自己使用较新版本的好处作为开发者？

15 java  architecture  backward-compatibility 

我对4 + 1架构视图模型如何映射到UML感到有些困惑。 维基百科提供了以下映射： 逻辑视图：类图，通讯图，顺序图。 开发视图：组件图，包装图 流程视图：活动图 物理视图：部署图 方案：用例图 纸张UML时序图的构建在对象生命周期概念作用提供了以下映射： 逻辑视图（类图（CD），对象图（OD），序列图（SD），协作图（COD），状态图图（SCD），活动图（AD）） 开发视图（包装图，组件图）， 流程视图（用例图，CD，OD，SD，COD，SCD，AD）， 物理视图（部署图），以及 结合了上述四个方面的用例视图（用例图，OD，SD，COD，SCD，AD）。 网页UML 4 + 1 View Materials提供了以下映射： 最后，白皮书《将4 + 1视图架构与UML 2结合使用》给出了另一个映射： 逻辑视图类图，对象图，状态图和组合结构 过程视图顺序图，通讯图，活动图，时序图，交互概述图 开发视图组件图 物理视图部署图 用例视图用例图，活动图 我相信进一步的搜索也会揭示其他映射。 尽管各种人通常有不同的看法，但我不明白为什么会出现这种情况。特别地，每个UML图都从特定方面描述系统。那么，例如，为什么一位作者认为“顺序图”描述了系统的“逻辑视图”，而另一位作者却认为它描述了“过程视图”呢？ 您能帮我澄清一下混乱吗？

15 architecture  uml  model  view 

在围绕MVC设计项目的体系结构时遇到一些问题。（这是一个C ++ / Marmalade SDK项目，我没有使用任何特定的MVC框架，而是创建了一个。） 在几篇文章中（例如在史蒂夫·伯贝克（Steve Burbek）的原始文章中），我一直在阅读“ MVC triad”的概念，这使我感到困惑，因为我从字面上理解了这个概念。当我第一次阅读它时，看起来应用程序是围绕“ MVC triad”单元构建的（我应该为每个UI单元构建一个单元），但是我发现这相当不灵活，我认为这并不是打算使用MVC的方式。然后，进一步研究该问题，我发现了控制器和视图紧密耦合的几个示例，即一对一关系-TextEditView具有TextEditController。 但是，当我回到项目时，发现使用一个控制器（按“逻辑单元”，如AddElementController）和该特定控制器的多个视图可能会很有用。 我显然在考虑类似AddElementController之类的东西，它应该具有某种选项卡式UI。我是否应该具有一个具有AddElementTabView的AddElementController以及用于选项卡的几个AddImageView，AddSoundView等？还是每个选项卡视图都应该有一个不同的“子控制器”？ 总而言之，关于MVC模式（不是X框架对此模式的特殊理解/实现），为一个控制器拥有多个视图是否正确，还是每个视图都应具有其特定的控制器？ 另外，在控制器上保留一些状态信息是否正确还是应该是无状态的（意味着状态应该放在某些非域状态模型上）？ 在此先感谢所有。

15 design  design-patterns  architecture  mvc 

我认为我对Windows 8消费者应用程序开发的期望有所了解。在WinRT之上创建一个新的基于Metro的UI，通过Marketplace将其部署到您的客户中，每个人都将赢得胜利。似乎很简单。不幸的是，我不从事这项业务。 我为大型企业开发内部业务线应用程序。当前，我们使用诸如WPF和Silverlight之类的.NET技术来创建可通过Web或ClickOnce轻松部署给我们用户的丰富UI。这些应用程序可以轻松支持WinXP和Win7，并且我们的开发人员可以使用XAML，这是一种非常可靠的UI技术。 WPF和Silverlight似乎在这一点上有可疑的期货，因此继续投资于这些股票有点令人担忧。但是Metro UI似乎不适用于企业应用程序，并且WinRT API在企业应用程序需要做的“典型”事情上有很大的局限性。 我应该如何设计当前已部署到WinXP和Win7的基于XAML的应用程序，以便它们在Win8上可支持并可以发展？ 出于这个问题的目的，假设ASP.NET之上的HTML5提供的功能不足以适合我要创建的应用程序。我知道我可以在某些应用程序中使用HTML5，但我试图弄清楚在不够的情况下应该怎么做。 编辑1： 这是对@Emmad Kareem的评论的回应。我同意Silverlight / WPF在短期内（2-5年）是可行的。但是，我们生产的应用程序的使用寿命可能非常长（10-20年以上）。因此，给定技术的长期生存能力是我们关注的问题。另外，我们担心，如果社区认为“ Silverlight / WPF开发”中的技术“过时”，那么找到对它们感兴趣的开发人员将越来越困难。我只是想了解我的选择，睁开眼睛做出决定。

15 architecture  enterprise-architecture  windows-8  forward-compatibility 

当涉及到utils和其他帮助类时，我在正确命名类和服务时遇到问题。 您将如何构造以下内容： EventService.cs EventServiceUtils.cs EventServiceValidators.cs EventServiceCoordinator.cs 等等... 我有与上述服务具有相同需求的多种服务。一种想法是将所有这些都分离到合适的名称空间中，使其看起来像这样： Services.EventService.EventService.cs //(the actual service) Services.EventService.Validators.DateValidator.cs Services.EventService.Validators.ParticipantValidator.cs Services.EventService.Coordinators.ParticipantCoordinator.cs Services.EventService.ExtensionMethods.Extensions.cs 等等。每个命名空间当然都是一个单独的文件夹。但这并不是100％，因为DateValidators其他服务中可能还有更多，这很容易导致不必要的引用。 并且还在Services.EventService.EventService.cs名称空间中包含类名称，这也不好。您可以使用Services.Event.EventService.cs，但是当然已经有一个具有该名称的实体。 这是领域模型。

15 c#  architecture 

杰夫·阿特伍德（Jeff Atwood）最近写了一篇关于Netflix实现“混沌猴子” 的博客文章。这是一篇非常高级的文章。我很好奇是否有人实际实施了该技术来测试系统。 我想我真正想问的是：您采用什么策略来确保您的体系结构能够在系统崩溃的一部分中生存下来？

15 c#  architecture  cloud-computing 

TDD是关于在测试的指导下设计代码的。 因此，通常不预先构建典型的层。它们应该在重构步骤中稍微出现。 域驱动的设计涉及许多技术模式，它们定义了完善的层，如应用程序层，基础结构层，域层，持久性层。 要从头开始DDD项目的编码部分，应如何操作？ 我是否应该严格让设计从测试中脱颖而出，这意味着没有关注点分离（没有层次）和重构以适合DDD技术模式？ 还是应该创建那些空层（应用程序，实体/域服务，基础结构），并让TDD独立地适合每个层（使用模拟在层之间进行隔离）？

15 architecture  testing  tdd  domain-driven-design 

标题说“ 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 

我们将要编写我们的第一个WPF应用程序，并逐渐熟悉MVVM模式。我们已经构建了许多Winform应用程序，并拥有对我们非常成功的体系结构。我们在转换该架构或确定我们的架构的某些部分适合MVVM模型时遇到了一些麻烦。 从历史上看，我们有一个Gui（主exe），然后它可以与BusinessLogic dll通信。BusinessLogic通过Web服务与DAL dll通信，并且DAL与数据库进行交互。DAL，BusinessLogic和GUI都引用相同的BusinessObjects dll。 向MVVM的某些过渡相当简单。我们的Gui将仍然包含视图，我们的BusinessOjbects将仍然包含模型，而我们的DAL将仍然与数据库交互（尽管实现它们的技术可能会发生变化）。 我们不确定的是我们的BusinessLogic组件。从历史上看，这将提供GUI调用的函数，然后在视图中填充控件（即GetCustomerList，它将返回Customer对象或典型的CRUD函数的列表）。 我们主要遇到的问题是MVVM模式是否需要一个附加组件来容纳ViewModels，还是我们只是改变了思维方式并将用作BusinessLogic组件的内容迁移到ViewModels？ 我们的BusinessLogic组件代表ViewModels吗？

15 architecture  mvvm 

上下文：我正在使用C＃ 我设计了一个类，为了隔离它并使单元测试更容易，我传入了它的所有依赖关系。它在内部没有对象实例化。但是，不是引用接口来获取所需的数据，而是让它引用通用的Funcs返回所需的数据/行为。当注入其依赖项时，我可以使用lambda表达式来实现。 对我来说，这似乎是一种更好的方法，因为在单元测试期间我不必做任何繁琐的模拟。另外，如果周围的实现有根本变化，则只需要更改工厂类即可；无需更改包含逻辑的类。 但是，我之前从未见过IoC这样做，这使我认为我可能会缺少一些潜在的陷阱。我唯一想到的是与未定义Func的C＃早期版本的轻微不兼容，在我看来，这不是问题。 使用泛型委托/高阶函数（例如Func for IoC），而不是使用更具体的接口时，是否存在任何问题？

15 architecture  interfaces  inversion-of-control  delegates 

在向我介绍软件体系结构和设计模式时，我注意到在大多数情况下，解释中都隐含了某些语言功能和设计细节。 例如，几乎任何文章或书籍都将使用类和接口来说明思想。在该主题上可以轻松找到的所有内容都会提到对象和OOP概念。 如果编写系统的语言根本没有这样的概念怎么办？例如，如果我使用动态类型且没有接口概念的Python或Node，该怎么办？如果我在接口是短暂构造（在运行时中不存在）的情况下使用TypeScript怎么办？如果我尝试使用函数式编程该怎么办？我应该忽略例如SOLID并寻找其他适合我的语言的概念吗？ 如果是，那是什么？不幸的是，据我所知，所有公认的范例都以某种方式引用了OOP概念和类型。如果没有，那么在将通用的体系结构和设计原则适应我的特定语言和用例时应该遵循哪些规则？ 您一般如何描述体系结构和语言之间的依赖关系？

14 design-patterns  architecture 

假设我们有一个实现功能F的软件模块A。另一个模块B实现了与F'相同的功能。 有多种方法可以消除重复的代码： 让A使用B的F'。 让B使用A中的F。 将F放入自己的模块C中，让A和B都使用它。 所有这些选项都会在模块之间生成其他依赖关系。他们以增加耦合为代价应用了DRY原理。 据我所知，在应用DRY时，耦合总是增加或至少增加到更高的水平。软件设计的两个最基本的原则之间似乎存在冲突。 （实际上，这样的冲突并不令人惊讶。这可能是使良好的软件设计如此困难的原因。我确实感到惊讶的是，通常在介绍性文本中未解决这些冲突。） 编辑（为澄清起见）：我认为F和F'的相等不只是一个巧合。如果必须修改F，则很可能必须以相同的方式修改F'。

14 design  architecture  dry  coupling 

我的工作很困难，因为我的同事似乎在展览 过早/不必要的优化工作 具有可疑抽象的过早重复数据删除 例如，我们使用了经过修改的VIPER体系结构。他实现了路由器组件的基类（使用泛型），作为实现第一个毒蛇堆栈的一部分，而实际上并不知道在其他路由器中将确切复制什么。现在我们不得不提供一种UseCase包含用例的类型，但是大多数路由器没有多个用例，只有一个。 为潜在的未来功能发明通用解决方案 例如，当我们在应用程序中只有两个这样的屏幕时，他写了一个用于填充静态单元格表​​格视图的管理器，他不知道设计将从无聊的垂直形式转变为更多的自定义形式UI，因此管理器无用。 选择偶然的复杂性 当他还表现出英语差的语言障碍时，我该如何应对？

14 architecture