Questions tagged «architecture»

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

2
如何解决循环包装的依赖性
我正在重构一个大型代码库,其中大多数类位于一个包中。为了获得更好的模块化,我为每种功能都创建了子包。 我记得在某处学习过包依赖关系图不应包含循环的信息,但我不知道如何解决以下问题:Figure在package中figure,Layout在package中layout,Layout需要该图执行布局,因此package layout依赖于package figure。但另一方面,a Figure可以Figure在其内部包含其他s,它们具有自己的Layout,这使得package figure依赖于package layout。 我有一些解决方案,例如创建一个实现并将其放入包中的Container接口。这是一个好的解决方案吗?还有其他可能性吗?FigureLayout 谢谢

3
如何仅向少数几个用户推出功能
我想问的一个很好的例子是Facebook的新时间轴功能。开始时,只有少数几个被允许访问时间轴。随着该功能在其工作方式上变得更加牢固并修复了一些错误,允许其他用户访问该功能。后来,允许大量用户访问该功能,现在,所有用户都可以使用该功能。开发团队如何管理这种功能? 我一直在考虑使用配置设置来通过配置文件和代码中的条件if语句有选择地控制访问(如果正在测试或生产中)。现在,尽管可以使用简单的功能,但我相信,如果我们尝试在更大的功能集中实现这一点,将变得难以管理。 以这种方式管理功能推出的最佳方法是什么?

11
连续创建和删除表是否表明存在体系结构缺陷?
最近,我与一位开发人员进行了讨论,该开发人员提到在程序开发过程中,他们会定期创建和删除表和列,同时使用新功能和合理的工作,并说使用敏捷开发过程是正常的。 由于我的大部分背景都是在瀑布式开发环境中进行的,所以我想知道这在敏捷开发中是否被认为是正确的,或者这可能是潜在问题的征兆,无论是程序体系结构还是遵循敏捷过程。

2
控制器应该以MVC模式将数据传递给视图吗?
我经常使用ASP.NET MVC(以及其他基于Web的MVC实现),但这是我从未确定的事情:控制器和视图是否应该通信? 当然,控制器应该选择要使用的视图,但是我的意思是控制器应该将数据传递给视图吗?我认为,如果视图期望来自控制器的数据,则它们将有效地捆绑在一起(一对控制器)。相反,我通常让视图与模型本身进行通信,并且独立于任何控制器。 我有正确的方法吗?还是这是没有一个正确答案的情况?在Web和其他环境中工作时答案是否会改变?当您具有强类型视图的概念(例如在ASP.NET MVC中)时,答案是否会改变?
11 architecture  mvc 

5
在旧版应用程序中启动一致的体系结构
我负责基于Asp.Net的大型网站。目前,它是一个网站(不是Web应用程序),一些Windows服务和许多类库。 数据层使用LLBLGEN 和Linq To LLBGen 的混合物,以及许多尚未重构的传统内联SQL实例。 有一些管理器类型的实现,但是在许多情况下,该应用程序都具有Smart UI反模式(即,类背后的代码中的业务逻辑过多) 该站点的流量相当大,性能还不错,但是我们正在将开发能力提高到大约10个团队,并且越来越明显的是,我们需要在现有中间件之上进行总体分层设计。 我的问题是从哪里开始?我们有10年的代码(其中有些实际上仍然只是在迁移ASP Classic东西),许多不同的方法和样式。 重构整个代码库是不现实的,并且可能是不希望的 我知道这不是一个新情况,关于如何解决这个问题是否有有用的想法或概念?

3
微型与单片服务器架构
我们当前正在开发我们的新产品/项目,它是针对某些特定工业/服务企业的客户端-服务器应用程序。我们正在构建一个服务器(仅C语言和Linux),该服务器在带有Java前端的TCP之上运行自定义协议。我们大约有20%的人员从事编码工作,并且面临着必须在微型或单核内核体系结构之间进行选择的情况。 我知道Micro vs. Monolithic通常与内核体系结构有关,但是我们专门讨论服务器。 为什么要使用自定义服务器而不是现有服务器? 我们的UI需求非常重要且非常动态,因此基于Web / Web浏览器的解决方案不合适。 统计处理在客户端非常重要,因此,浏览器也无济于事。(当然,我们可以在服务器端进行处理,然后将处理后的数据传递给客户端,但这将意味着服务器上的大量负载和客户端资源的浪费)。 此外,利用至少三种技术(JS / HTML / CSS)来管理单个事件,就可以像在沙漠风暴中扫除房屋一样获得整个体验-您扫除n次,灰尘积聚n + 1次。 微型和整体服务器呢?你在说什么? 考虑以下(假设的)客户端请求: request-id: 123 request-service: HistoricDataSets request-message: Fetch all records upto the year 2010 收到此类请求后,服务器通常会这样做(为简单起见,我们忽略了诸如线程和派生之类的并发技术): 解析请求字符串 确定动作(HistoricDataSets LIMIT Year (2010)在我们的例子中为Fetch ) 与持久层(在我们的示例中为Oracle)交互并获取数据。 根据协议格式化数据。例如: response-id:123 成功:true 响应文本:DataSets 用这样格式化的数据响应客户端。 这就是我们所说的单片服务器(类似于单片内核,其中所有OS工作都在内核空间中完成)。 再次考虑到相同的请求,这一次是服务器(我们为简单起见,我们仅假设共享内存为IPC): 将请求放入Parser进程的共享内存 在Parser解析字符串,确定任务和指示Executioner执行任务的过程。 在Executioner然后将数据传递到Fomatter方法,该方法中,数据格式化为一个协议串后,返回到服务器。 服务器将其分派给客户端(响应)。 当然,相反的Parser,Executioner而且Formatter它可能是一个单一的,而是独立的进程。这就是我们所说的微型服务器(类似于微型内核,几乎不需要做任何事情)。服务器实际上只是在侦听和响应,而所有步骤都由不同的进程来处理。 …

1
架构模块化服务应用程序
我正在考虑设计一种本质上是模块化的新解决方案,并希望创建一个支持该设计的结构,以便将来轻松进行扩展,明确分离关注点,按模块进行许可等。在网络上发现的关于模块化或组合应用程序的是以UI为中心的,专注于Silverlight,WPF等。就我而言,我正在开发WCF服务应用程序,该程序将由从事各种UI项目的其他开发人员使用。 背景 我的项目的目标是创建一个集中的业务/域逻辑源,以支持我们的多个当前重复流程,规则等的业务应用程序。虽然并非可以实现模块化的所有好处,但我想抓住建立一个可以利用我们可以利用的那些部分的框架的机会。 我通过查看服务应用程序公开的API来开始设计。显然,可以按照我所考虑的模块化路线来隔离服务。例如,我将拥有FinanceService,InventoryService,PersonnelService等服务,这些服务将我的服务操作分组以在API中提供高内聚性,同时保持较低的耦合度,因此客户端仅需使用与他们的应用程序相关的服务。 对于我来说,我可以为每个服务分别拥有单独的模块,例如MyApp.Finance,MyApp.Inventory,My.Personnel等。跨领域关注点和共享类型将在MyApp共享程序集中。从这里我有点束缚。 (哦,我应该提一下,我将使用IoC容器进行依赖注入来保持应用程序的松散耦合。我不会提及哪个容器,因为我不想打开Pandora的盒子!) 在MyApp.ServiceHost中,我将创建一个与每个模块相对应的服务宿主文件(.svc),例如FinanceService.svc。服务主机需要服务的名称,该名称与配置文件中的信息相对应,该配置文件包含定义服务合同的接口。然后,将IoC配置用于映射要使用的接口的具体实现。 1.服务层应该实现API并委托给模块,还是应该使模块自包含(因为它们包含与该模块相关的所有内容,包括服务实现)? 解决该问题的一种方法是拥有一个MyApp.Services“模块”,其中包含服务合同的实现。每个服务类都简单地委派给包含该操作的域逻辑的相应模块中的另一个类。例如,MyApp.Services中的FinanceService WCF类委托给另一个接口,该接口在Finance模块中实现以执行操作。例如,这将使我能够维护精简的服务外观并将实现“插入”到服务实现中,并且无需使模块担心WCF。 另一方面,也许每个模块都是独立的,因为它具有接口和实现。服务主机引用模块中的服务合同接口,并且IoC也配置为使用模块中的适当实现。这意味着除了添加新的.svc文件和IoC配置信息外,无需更改服务层即可添加新模块。 我正在考虑如果从标准WCF切换到RESTful服务接口,或者转而使用RIA服务之类的影响。如果每个模块都包含服务合同的实现,那么如果我更改服务技术或方法,则必须在每个模块中进行更改。但是,如果外观是其自己的模块,那么我只需要换出该部分即可进行更改。然后,这些模块将必须实现一组可能在共享程序集中定义的合同(接口)的不同集合??? 2.处理模块之间的资源共享和/或模块之间的依赖关系的最佳方法是什么? 以接收操作为例。乍一看,这很有意义,因为进货是库存功能,因此进入库存模块。但是,在财务方面,我们还需要生成收据并授权付款。 一方面,我希望使用某种类型的域事件/消息传递来传达操作。库存模块引发一个GoodsReceivedEvent,该事件由Financial模块处理以生成收据并启动付款过程。但是,这意味着财务模块需要了解已收到的库存项目。我可以简单地通过ID来引用它们,但是如果我需要收据的其他信息,例如名称和/或描述,单位成本等,该怎么办?每个模块都拥有自己的版本的清单项目以适应该模块的需求是否有意义?在这种情况下,财务模块在处理GoodsReceivedEvent时将必须执行自己的库存项目查找。 ... 我之所以使用此示例,是因为我已经与各种ERP系统进行了大量合作,并且知道它们是采用这种类型的模块化设计的-我只是不知道如何操作。我上面也没有明确提及,但是我更喜欢遵循域驱动设计原则来设计解决方案,并相信这种类型的模块化恰好适合该领域。 非常感谢我对此有所帮助。

6
我知道如何编程,如何学习编程,但是您如何/在何处学习如何正确制作系统?[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,以使它成为软件工程堆栈交换的主题。 4年前关闭。 制作系统时,需要考虑很多事情,例如,基于Web的系统,用户登录并彼此交互,创建和编辑内容。现在,我必须考虑安全性,验证(我什至都​​不认为我100%地确定了其中的含义),“确保用户不要互相踩踏”(这是术语?),从而防止了许多错误确保数据库数据不会因意外情况而出现问题?所有这些我不知道如何学习或在哪里学习的东西,有一本书关于这种东西吗?就像我说的那样,编写代码和实际编写正确的代码之间似乎有很大的区别,知道我的意思吗?我觉得我目前的编程工作缺少我所描述的内容,以后我会看到它引起的问题,然后问题就很难解决了,因为存在数据并且人们正在使用它。那么,有人可以将我指向这类学习的书籍或资源或正确的编程子集吗? PS:随时纠正我的标签,我不知道我在说什么。 编辑:我假设我写的一些示例也适用于其他类型的系统,我只是不知道任何其他好的示例,因为我主要从事网络工作。

4
规则引擎的使用如何影响应用程序的设计,实现和性能?
我对规则引擎的能力感兴趣: 启动并迭代业务驱动逻辑 让“业务用户”而不是开发人员执行这些规则的实际修改 大致理解业务规则 另外,使用规则引擎是否会影响应用程序的质量? 如果要部署到一台计算机的安装程序,架构与使用数千台计算机的多层基于云的分布式架构,规则引擎的使用是否会发生变化?会有什么不同?


5
架构描述文件是否违反了DRY原则?
DRY原则(不要重复自己)指出:“每条知识都必须在系统中具有单一,明确,权威的表示形式。” 在大多数情况下,这是指代码,但它通常还扩展到文档。 据说每个软件系统都有一个体系结构,无论您是否选择它。换句话说,您构建的软件具有结构,而“已构建”结构就是软件的体系结构。 由于构建的软件系统具有体系结构,因此创建该系统的体系结构描述是否违反DRY原理? 毕竟,如果您需要了解架构,那么您始终可以只看一下代码...

2
应用程序服务层调用数据库功能。架构不好?
场景: 堆栈:Java,Spring,Hibernate。 型号:客户端-服务器应用程序。 模式:模型-视图-控制器(MVC)。 服务层类具有三种行为: 一些服务在方法内具有业务规则,并将持久性委托给应用程序。喜欢: EntityManager.save(entity); 一些服务只是调用数据库函数(传递参数),例如: CallableStatement cls = con.prepareCall(“ {call databaseFunction(args)}”); 某些服务同时具有两种行为的方法。 我的问题: 让应用程序服务直接调用数据库功能有什么问题吗?这不是不好的做法吗?适用于这样的项目的架构模型是什么? 在同一服务中混合行为是否有问题?如交易和一致性? 在维护的情况下,这种封装是否使开发人员不清楚他也应该更改数据库中的功能?如何避免这种情况? 这种情况是否会在世界各地的其他应用程序中发生,或者仅仅是架构错误?

2
多租户或多实例?
我试图构建一个基于Web的SaaS解决方案,但遇到了不确定使用多租户或多实例的道路。我将尝试描述我要实现的目标,以及每种方法的优缺点(根据我的阅读,我的观点)。请提出您的建议,以防万一我错过了其他任何方法。 正如我提到的那样,我要构建的应用程序是一个SaaS解决方案,公司可以在其中创建帐户,每个帐户/公司都有自己的用户,客户,产品,服务等。每个用户;谁是公司员工;与一个帐户/公司相关的信息将只能访问其公司的客户,产品和服务。公司可以拥有无​​限数量的客户,产品和服务,因此每个公司都应该拥有自己的数据中心。 为此,我决定创建一个共享数据库(保存所有用户凭据以用于登录)和多个数据库共享架构(每个帐户/公司的数据库)。基本上,多租户。 然后有人建议使用多实例代替,每个公司将有自己的应用程序实例(即代码,库,数据库,框架等),与其他公司完全分开。这听起来更好,因为我不必在需要确保每个租户的用户只能访问其公司数据的额外层上打理。我认为值得一提的是,我依靠Docker来实现这种方法(我以前从未使用过),但是我认为它缺乏将来我将需要的功能(以后会更多)(至少我没有这样做)。一点点搜索就找不到它们)。 但是,每种方法都各有利弊,因此我无法决定采用哪种方法。这是一个列表,但由于我对它们都不了解,所以对我几乎一无所知,因此可能存在一些我不知道的问题,或者是针对我在网上找不到的问题的解决方案:[每种方法都有我跟着一个一个的比较的有序列表] 多租户: 共享的主机/硬件,共享的代码和多数据库。 这是容易扩展的代码并修复错误的功能(共享代码)。 在不更改代码的情况下,很难扩展硬件(可以使用云服务)或将单个租户的数据库移至另一个系统。 最重要的是,如前所述,我需要在系统中添加一个额外的层,以确保用户实际上属于他/她的公司,而不访问其他公司的信息。 多实例: 共享或不共享的主机/硬件,每个实例的代码以及每个实例的数据库。 这是很难扩展功能或修复的错误(我不知道是否有办法做到这一点在码头工人在那里你可以添加功能/特性,以一个实例或码头集装箱,并将其部署到其他人)。 这是更容易对整个实例移动到不同的主机/硬件。 作为实例,我不需要照顾该层,因为每个实例将拥有自己的数据库。 万一我想手动做任何事情(例如为每个租户手动创建一个实例),所有的优点和缺点都是多余的,这就是为什么我怀疑Docker解决方案的原因,除非有一种解决方法,这也许是主要的问题的原因。如果您能通过参考解决方案来回答问题,以及为什么您认为这种方法比其他方法更好,我将不胜感激。 如果有帮助(也许?),我们使用Laravel作为后端的主要框架(全部为RESTful)。

4
如果微服务架构需要每个微服务单独的数据库,那么它的成本太高且难以管理。为什么我们甚至需要它?
我读到有关微服务的信息,对于每个服务创建一个单独的DB来实现隔离似乎不合逻辑。我可以仅使用Web服务和单个数据库来实现相同的目的。为什么我们甚至需要它?分开数据库的东西是无聊的。还是我明明是错?你能指导我吗?

4
以适当的方式将条件替换为多态吗?
考虑两个类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) } } 该代码如何重构?闻起来很香

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.