Questions tagged «architecture»

软件系统的高级设计和描述。架构设计提取了实现,算法和数据表示的细节,以专注于“黑匣子”组件的交互。

2
前端用后端语言编写![关闭]
已关闭。这个问题需要细节或说明。它当前不接受答案。 想改善这个问题吗?添加详细信息并通过编辑此帖子来澄清问题。 6年前关闭。 根据我在Web开发中的经验,我知道PHP,Java,Python等语言用于后端开发(在服务器上运行的软件),对于前端语言,则使用JS / HTML / CSS。 但是我看到许多公司都说,例如,PHP用于前端开发,而python用于后端。 这是否意味着PHP是通过REST,RPC等调用使用其他语言编写的其他服务的前端?

2
我应该缓存数据还是访问数据库?
我没有使用任何缓存机制,并且想知道在以下情况下我在.net世界中的选择是什么。 我们基本上有一个REST服务,其中用户传递类别的ID(思考文件夹),并且此类别可能有很多子类别,每个子类别可以具有1000个媒体容器(思想文件引用对象),其中包含有关以下内容的信息可能位于NAS或SAN服务器上的文件(在这种情况下,文件是视频)。这些类别之间的关系与一些权限规则和有关子类别的元数据一起存储在数据库中。 因此,从UI角度来看,我们有一个惰性加载的树控件,该控件由用户通过单击每个子文件夹来驱动(以Windows资源管理器为例)。他们进入视频文件的URL后,便可以观看视频。 随着系统的发展,用户数量可能会增长到1000,而子类别和视频的数量可能会在10000。 问题是我们应该在每个请求访问数据库的地方继续当前的工作方式,还是应该考虑缓存数据? 我们正在使用IIS 6/7和Asp.net。

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)。

5
微服务:MonolithFirst?
我一直在研究微服务体系结构,以期全面了解所有优缺点,何时何地为什么。等等。我正在阅读/观看的许多信息都来自ThoughtWorks(Martin Fowler,Neal Ford等)。 al)。 马丁·福勒(Martin Fowler)在该主题上的大部分工作都还存在数年,那时微服务(如果不是一般实践,在编程中是家喻户晓的名字)还很年轻,因此,我对其中的大部分内容持保留态度。 特别要注意的是: 当我听到有关使用微服务架构的团队的故事时,我注意到了一种常见的模式。 几乎所有成功的微服务故事都始于一个庞大的整体,并且被分解了 在几乎所有我听说过从头构建为微服务系统的系统的情况下,它都遇到了严重的麻烦。 这种模式使我的许多同事争辩说,即使您确定应用程序足够大,也值得这样做,但您不应该使用微服务启动新项目。。 (参考:https : //martinfowler.com/bliki/MonolithFirst.html-强调他们的) 现在,三年后的今天,微服务这个词更普遍了,人们普遍同意一个新系统通常可以通过拥有更大(比微服务大但比整体式小)的服务块来更好地服务,并且作为进化措施的一部分,它们是否更细化? 或者,与上述陈述相比,是否有规范从头开始使用粒度微服务架构开始项目? 似乎是理智的一般方法,但对社区的思想感到好奇。

2
我应该在服务和存储库之间使用一个层来构建干净的架构-Spring
我正在架构中,它将为Web客户端和移动应用程序提供rest api。我正在使用Spring(spring mvc,spring data jpa,... etc)。域模型使用JPA规范编码。 我正在尝试应用干净架构的一些概念(https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html)。并非全部,因为我将保留jpa域模型。 通过各层的实际流量是这样的: 前端 <-> API服务 -> 服务 -> 存储库 -> 数据库 前端:Web客户端,移动应用 API服务:Rest控制器,在这里我使用转换器和dto并调用服务 服务:与实现的接口,并且包含业务逻辑 存储库:具有自动实现的存储库接口(由spring data jpa完成),它包含CRUD操作以及一些sql查询 我的疑问:我应该在服务和存储库之间使用额外的一层吗? 我正在计划这个新流程: 前端 <-> API服务 -> 服务 -> 持久性 -> 存储库 -> 数据库 为什么要使用这个持久层?正如它在干净的体系结构文章中所说的,我希望有一个访问不可知的持久层的服务实现(业务逻辑或用例)。如果我决定使用其他“数据访问”模式,例如,如果我决定停止使用存储库,则不需要更改。 class ProductServiceImpl implements ProductService { ProductRepository productRepository; void save(Product product) { // do …

3
在松散耦合的微服务架构中,如何跟踪依赖关系?
现代程序中流行的高级体系结构选择是基于REST的微服务系统。这具有几个优点,例如松耦合,易于重用,对可用技术的限制有限,高可伸缩性等。 但是我预见到的这种架构中的问题之一是对应用程序依赖项的可见性不佳。例如,假设我有一个应用程序,该应用程序每天使用一组REST调用。该应用程序还使用第二组REST调用,但每季度仅使用一次。如果我要扫描过去一周的日志,我会看到所有的每日校准数据,但可能看不到季度调用。当需要重构时,每季度调用的中断风险很高。 可以使用什么模式或工具来减少这种风险,并提供对松散耦合体系结构的依赖性的更大可见性?

1
在MVP模式中,View应该基于UI内容实例化Model对象,还是仅将这些内容作为参数传递给Presenter?
我正在开发的Android应用程序中使用MVP模式。 我基本上有4个元素: 可以在其中添加新用户的AddUserView: AddUserPresenter UserInfo(pojo) UserInfoManager(业务逻辑和存储管理器) 我的问题是: 当我在AddUserView中按下“添加”按钮时,它应该获取文本视图的内容,实例化一个新的UserInfo并将其传递给Presenter。还是AddUserView应该只获取textViews内容并将其传递给AddUserPresenter,而后者实际上将实例化UserInfo并将其传递给UserInfoManager?

1
仅在很少有写入的情况下才使用事件源吗?
我正在阅读事件源,不能停止问自己,这是否仅在非常罕见的情况下才有意义,在这种情况下,写操作很少或需要进行军事级审核。 具有非凡用途的非例外系统每天可能会产生成百上千的写入,相当于每年运行一百万或2次写入(因此发生事件)。与从传统存储中直接读取的内容相比,合并数百万个对象(事件)只是为了获得当前状态,这听起来很荒谬。但是,事件源位于某些性能最高的系统(例如LMAX)的背后。 那么,我想念什么?从事件流恢复状态是否通常已经完成?还是这种想法很少需要这样做,而是完全使用其他存储来进行常规操作(即使用CQRS的查询存储),并且仅在特殊情况下(例如复制,审核等)从事件中恢复?


3
REST是否仅限于乐观并发控制?
语境 由于REST体系结构样式的无状态性(涉及每个请求完全独立),导致服务器从不存储有关客户端的任何信息。 因此,悲观并发控制不合适,因为这将要求服务器存储哪个客户端获得资源锁定。然后在Etag标头的帮助下使用乐观并发控制。(顺便说一句,正如我在那儿问的/programming/30080634/concurrency-in-a-rest-api) 问题 乐观并发控制机制的主要问题在于,您始终允许所有客户端执行任何操作。 我想避免这种情况,而不会破坏REST的无状态原则。我的意思是,所有客户端都无法随时执行任何操作。 题 在我看来,采用半乐观并发控制机制是可能的,例如: 客户可以请求令牌 只能生成一个令牌,并且有效期有限 要对资源(例如POST或PUT)执行操作,客户端必须将此令牌作为请求正文(或标头?)的一部分提供。没有令牌的客户端无法执行这些操作。 它与开放式并发控制非常相似,不同之处在于,只有一个客户端可以执行某些操作(获得令牌的操作)……与“所有客户端可以执行所有操作”相反。 这种机制是否与REST架构风格兼容?它打破了它的任何约束吗?我当时想问一下SO,但这似乎是一个与软件设计有关的高级问题。

4
如何在不强制进行层次结构的情况下使对象彼此交互和通信?
我希望这些问题能使我的问题更清楚-但是,我完全理解它们是否愿意,所以请让我知道是否是这种情况,然后我将尝试使自己更加清楚。 认识BoxPong,这是我做的非常简单的游戏,以熟悉面向对象的游戏开发。拖动框以控制球并收集黄色的东西。 制作BoxPong可以帮助我提出一个基本问题:除其他事项外,我如何才能具有相互交互的对象?换句话说,有没有一种方法使对象不是分层的而是共存的?(我将在下面进一步详细介绍。) 我怀疑对象共存的问题是一个普遍的问题,因此我希望有一个既定的解决方法。我不想重新发明方形齿轮,因此我想寻找的理想答案是“这是一种通常用于解决您的问题的设计模式”。 尤其是在像BoxPong这样的简单游戏中,很明显,在同一级别上存在或应该存在少量对象。有一个盒子,有一个球,有一个收藏品。我可以用面向对象的语言表达的所有内容,尽管看起来似乎都是严格的HAS-A关系。这是通过成员变量完成的。我不能只是开始ball并让它做它的事情,我需要它永久地属于另一个对象。我已经设定,使游戏的主要对象有一个箱子,并依次盒子有一个球,并有一个比分反超。每个对象也都有一个update()方法,该方法计算位置,方向等,我走了类似的方法还有:我所说的主要游戏对象的更新方法,它调用了所有儿童的更新方法,它们依次调用所有的更新方法他们的孩子。这是我看到的制作面向对象游戏的唯一方法,但我认为这不是理想的方法。毕竟,我不会完全把球看作是属于盒子的东西,而是要处于同一水平并与之交互。我想可以通过将所有游戏对象都转换成主要游戏对象的成员变量来实现,但是我看不出有什么解决方法。我的意思是……撇开明显的混乱,如何让球和盒子互相认识,也就是互动? 还存在对象之间需要传递信息的问题。我有很多为SNES编写代码的经验,您几乎一直可以访问整个RAM。假设您要为Super Mario World定制敌人,并且希望它删除Mario的所有硬币,然后只存储零以解决$ 0DBF,这没问题。没有任何限制说敌人无法访问玩家的状态。我想我被这种自由宠坏了,因为对于C ++之类的东西,我经常发现自己在想如何使其他对象(甚至全局对象)可以访问值。 以BoxPong为例,如果我希望球从屏幕边缘弹起怎么办?width和height是的属性Game类,ball可以访问它们。我可以传递这些类型的值(通过构造函数或需要它们的方法),但是这只是对我的不好的做法。 我想我的主要问题是我需要对象彼此了解,但是我看到的唯一方法是严格的层次结构,这是丑陋且不切实际的。 我听说过C ++上的“朋友类”,并且知道它们是如何工作的,但是如果它们是最终解决方案,那么为什么我看不到friend每个C ++项目中都充斥着关键字呢?并不是每种OOP语言都存在这个概念吗?(我最近才了解到的函数指针也是如此。) 预先感谢您提供任何形式的答案-再次提醒您,如果有部分内容对您没有意义,请告诉我。

1
加速对两个数据仓库的数据访问的最佳方法?
我正在进行一个商业智能项目,该项目将要求抽象地访问两个现有数据仓库。我需要设计一个应用程序体系结构,以允许自助服务业务智能合并数据并提供两个现有仓库的单一视图。我想出了这样的东西: 我在虚拟化/缓存方面苦苦挣扎,想知道是否有任何企业设计模式可以解决我的问题。这样的体系结构是否可以抽象数据仓库中的星型模式?我正在研究诸如Red Hat JBoss数据虚拟化和Red Hat JBoss数据网格等产品。 我们目前不使用Hibernate,而我对数据网格的理解是它们是键值存储或对象存储,因此不适合缓存关系模型。我还应该提到,我们热衷于在自助服务仪表板部分使用供应商产品,但是如果供应商无法为我们提供所需的一切,我们最终可能会在此区域中进行一些自定义构建。

1
设计一个应用程序框架,该框架将允许每个实现自定义UI的各个部分
我的任务是设计一个应用程序框架,该框架将允许每个实现自定义用户界面的各个部分。一个这样的例子就是实现(现在称它为客户端)可以定义要返回到特定屏幕的集合视图单元格。该框架仅负责出售适当的对象,以使构建应用程序变得更加容易,因为我们将构建一些外观相似的实例。 我目前对框架的方法是设计一个协调控制器,该控制器负责整个App中的所有演示和解雇事件。默认的Coordination Controller售卖框架内所有默认视图控制器,它们全部执行其相关任务,而不必提供配置的UI。例如:一个控制器将显示一个包含模板单元格的集合视图,没有什么特别的。这种设计的好处在于,它消除了控制器之间的耦合,还允许客户端覆盖默认的协调器,并为特定任务返回全新的视图控制器。 我遇到的问题是如何设计该框架,以允许客户端将自己的自定义UI添加到App中。 方法一 使框架需要一个视图工厂,并让该视图工厂负责出售所有相关视图。因此,在App Delegate中,我们可能会强制客户端创建一个CollectionViewCellFactory例如,并且该接口定义了任何符合类需要提供的所有单元。我继承了这种设计的代码库,并因为它过于抽象和可定制,而放弃了它。它为App的各个方面提供了大量的工厂,这为每个App的建立时间增加了几天的时间。 方法二 每个视图控制器都指定子类挂钩或设置API,以允许在运行时定义这些自定义UI类(类似于UISplitViewController允许调用者使用viewControllers属性设置控制器的方式)。为此,每个客户只需将基本协调控制器和每个控制器的表示形式子类化即可;在控制器上设置适当的值,以实现所需的UI。就像是 viewController.registerReusableCellsBlock = ^(UICollectionView *collectionView){ //perform custom registration } viewController.cellDequeueBlock = ^UICollectionViewCell<SomeProtocol> *(UICollectionView *collectionView,NSIndexPath *indexPath){ //dequeue custom cells } 当前,我将视图的数据源分离到一个单独的对象中,以提高可重用性并防止ViewController膨胀。这使得对视图控制器进行子类化以提供单元的接口更加困难,但并非不可能。 方法3 尝试设计框架并预期其使用可能是一个坏主意。也许最好的选择是允许子集具有最大的控制权,即使设置成本相对较高。然后,为多个客户构建了该模型之后,我可能会注意到出现的模式并开始沿路线进行优化。 我了解如何在框架内部进行自定义,而我正在努力解决的问题是如何最好地定义一个接口,该接口定义客户端对框架的潜在自定义点。 TL; DR 界面最复杂的部分涉及嵌套在“集合视图”单元格内的“集合视图”。这允许单元的水平分页和垂直滚动。这可以通过拥有一个管理水平单元格并使用新数据源配置每个单元格的收集视图的数据源来实现。 如何设计一个允许所有这些单元都可自定义的接口?

4
在DAL和BLL层之间分离检索数据和业务对象
在发布此问题之前,我做了一些研究。在其他问题或帖子中,下面提供其中一个。我不清楚如何确定。 数据访问层中的业务对象 我有一个存储库,业务层调用该存储库以检索数据。例如,说我有以下BLL和DAL类: class BllCustomer { public int CustomerId {get; set;} public String Name {get; set;} public BllAddress Address {get; set;} } class BllAddress { public int AddressId {get; set;} public String Street {get; set;} public String City {get; set;} public String ZipCode {get; set; } } class DalCustomer { …

2
REST还是多层异构系统中的消息队列?
我正在为三层系统设计REST API,例如:Client application-> Front-end API cloud server-> user's home API server (Home)。 Home是家用设备,应该Front-end通过Websocket或长时间轮询来保持连接(这是我们违反REST的第一个地方,以后还会更糟)。Front-end大多数情况下会将Client请求传送到Home连接并处理一些呼叫本身。有时会Home向发送通知Client。 Front-end并Home具有基本相同的API;Client可能是Home通过LAN直接连接。在这种情况下,Home需要Client在Front-end自身上注册一些操作。 该系统中REST的优点是: REST是人类可读的; REST具有明确定义的动词(如CRUD),名词和响应代码到协议对象的映射。 它可以通过HTTP运行并传递所有可能的代理。 REST的反对意见是: 我们不仅需要一种请求-响应通信方式,还需要一种发布-订阅方式。 HTTP错误代码可能不足以处理三层通信错误。Front-end可能返回202 Accepted异步调用只是为了发现必要的Home连接断开了,应该已经连接了503; Home需要向发送邮件Client。Client将必须进行轮询Front-end或维护连接。 我们正在考虑通过Websocket上的WAMP / 高速公路来获得发布/订阅功能,这让我惊讶的是它已经看起来像消息队列。 是否值得评估一种消息队列作为传输方式? 看起来像消息队列相反是: 我需要在消息级别上自己定义CRUD动词和错误代码。 我读到一些有关“较高的维护成本”的信息,但这意味着什么? 这些考虑有多严重?

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.