Questions tagged «architecture»

我一直在开发将支持许多用户的应用程序。问题是我不知道如何验证客户端/用户。 我正在构建一个http://quickblox.com/之类的应用程序，在该应用程序中我将向用户提供凭据，他们将使用这些凭据来构建N个应用程序，在这些应用程序中，他们无法输入用户名和密码来进行身份验证。 让我们假设它如下。（就像QuickBlox一样） 1.用户在我的网站上创建帐户。 2.用户可以创建N个API密钥和保密凭证。（对于多个应用程序） 3.用户将在其应用程序（Android，iOS，Javascript等）中使用这些凭据与我的REST API进行通信。（REST API具有读写访问权限。） 我的顾虑？ 用户会将其凭据（API密钥和秘密密钥）放入他们构建的应用程序中，如果有人获得了这些密钥并尝试模仿用户该怎么办？（通过反编译APK或直接查看JavaScript代码。 我在某处错了吗？我对构建这种三级用户机制感到困惑。

14 design-patterns  architecture  api-design  authentication  enterprise-architecture 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 4年前关闭。 我为一家拥有250名开发人员的中型公司工作。不幸的是，许多应用程序都陷入了过程性思维之中，一些团队不断交付大型事务脚本应用程序，而实际上该应用程序包含丰富的逻辑。他们还无法管理设计依赖性，最终得到的服务依赖于另一批大量的服务（“泥浆大球”的一个清晰示例）。 我的问题是：您能否建议如何传播这种知识？ 我知道问题的表面在于这些应用程序的体系结构和设计不佳。另一个问题是，有些开发人员反对编写任何类型的测试。 我正在做一些改变这种情况的事情（但是我要么失败，要么改变太小了） 关于设计原理（SOLID，简洁代码等）的运行演示。 关于TDD和BDD的研讨会。 指导团队（这包括使用声纳，findbug，jdepend和其他工具）。 IDE和重构讲座。 我将来打算做的几件事（但我担心它们可能不好） 组成一个由OO传播家组成的团队，他们在不同的团队中传播OO的思维方式（这些人每隔几个月就要更换团队）。 运行设计审查会议，以批评设计并提出改进建议（即使由于时间限制而未完成改进，我认为这可能会很有用） 。 我在我的教练团队中发现的一件事是，一旦我离开他们，他们就会恢复到原来的做法。我知道我不会花很多时间陪伴他们，通常只有一个月。因此，无论我在做什么，它都不会粘住。 对不起，这个问题让我无奈，但写这个的替代方法是打我的头，直到我晕倒。

14 design  learning  object-oriented  architecture 

我最近建议为某个项目中的某个类实施链接方法，以便可以提高代码的可读性。我得到了一个“流畅的接口，不应该只是为了方便而实现，而是为了语义”，并拒绝了我的建议。我回答我不是在建议使用流畅的界面，而是将方法自身链接（可以相互混淆，请在底部阅读）以提高可读性和编码舒适度，但该建议再次遭到拒绝。 无论如何，这让我想到也许总是以不应该返回任何内容的方法（例如，setter）返回“ this”，这可能会导致一种不好的做法。 我的问题是：可以将先前的惯例视为不良做法或滥用吗？为什么？我认为没有任何性能缺陷，还是存在？

14 architecture  coding-standards  readability  method-chaining 

在过去的一年中，我使用依赖注入和IOC容器创建了一个新系统。这教会了我很多关于DI的知识！ 但是，即使在学习了概念和正确的模式之后，我仍然认为将代码解耦并将IOC容器引入旧版应用程序是一个挑战。该应用程序足够大，以至于真正的实现将是压倒性的。即使理解了价值并准予了时间。谁有时间抽出这样的东西？ 当然，目标是将单元测试引入业务逻辑！ 与防止测试的数据库调用交织在一起的业务逻辑。 我已经阅读了这些文章，并且了解了这篇Los Techies文章中描述的穷人依赖注入的危险。我了解它并没有真正分离任何东西。 我知道它可能涉及很多系统范围的重构，因为实现需要新的依赖项。我不会考虑在任何大小的新项目中使用它。 问题：可以使用穷人的DI 将可测试性引入旧版应用程序并开始滚动吗？ 另外，使用穷人的DI作为真正依赖注入的基层方法是否是教育该原理的需求和收益的有价值的方法？ 您是否可以重构具有数据库调用依赖关系的方法，并将该调用抽象到接口后面？简单地拥有这种抽象将使该方法可测试，因为可以通过构造函数重载传递模拟实现。 将来，一旦获得支持者的支持，就可以对该项目进行更新以实现IOC容器，并且构造函数将在那里使用抽象。

14 architecture  dependency-injection  legacy  inversion-of-control 

假设我们有一个任务记录系统，当记录一个任务时，用户指定一个类别，并且该任务默认为“未完成”状态。在这种情况下，假定类别和状态必须作为实体实施。通常我会这样做： 应用层： 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 …

14 architecture  domain-driven-design  repository  domain-model  entity 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 5年前关闭。 我想知道多少Java认证（SCJP，SCWCD和其他认证）对于架构师职位很重要。如果一个人在Java开发方面拥有良好的经验，并且想要在架构师级别上追求自己的职业，那么你们是否认为他需要获得其CV认证。他是否从未担任过首席开发人员角色？ 如果您进行我的建筑师职位面试。我曾在多个团队工作过5年，担任过Java Web开发人员。切勿领导任何人。我的简历上有认证徽章。 开发人员如何使自己的职业道路成为团队中的建筑师？

14 java  architecture 

我正在使用MVVM模式构建WPF应用程序。现在，我的视图模型调用服务层以检索模型（与视图模型无关）并将其转换为视图模型。我正在使用构造函数注入将所需的服务传递给viewmodel。 它易于测试，并且适用于几乎没有依赖关系的viewmodel，但是当我尝试为复杂模型创建viewModels时，我就有了一个构造函数，其中注入了很多服务（一个用于检索每个依赖关系和所有可用值的列表）绑定到itemsSource）。我想知道如何处理这样的多种服务，并且仍然拥有一个可以轻松进行单元测试的视图模型。 我在考虑一些解决方案： 创建一个包含所有可用服务作为接口的服务单例（IServices）。示例：Services.Current.XXXService.Retrieve（），Services.Current.YYYService.Retrieve（）。这样，我就没有一个包含大量服务参数的庞大构造函数。 为viewModel使用的服务创建外观，并将此对象传递到我的viewmodel的ctor中。但是，然后，我必须为我的每个复合视图模型创建一个外观，这可能会有点多... 您认为实现这种架构的“正确”方法是什么？

14 architecture  dependency-injection  mvvm 

我知道这是一个广泛的问题，所以我将尽量具体。这个问题比技术性问题更像是一个“组织性”问题。 我们有一个包含以下主要组成部分的多面项目： 服务器，托管核心业务逻辑（数据模型） 使用核心业务逻辑的客户后台 也使用核心业务逻辑的应用程序API（REST） 有使用应用程序API的智能手机应用程序（iOS和android） 还有另一个平板电脑应用程序（android）与使用相同应用程序API的智能手机不同。 很快，我将在活跃的客户中投入生产。作为任何项目，我都需要随着时间的推移维护所有不同的组件。这意味着可以升级以下所有内容： 服务器中核心业务逻辑的代码（由后台，API使用，并且副作用是由移动应用程序使用） API本身（由智能手机和平板电脑应用程序使用） 所有移动应用（通过appstore / googleplay） 当然，服务器端部分（核心业务逻辑代码和API代码）可以由我自己立即更改。但是，客户端必须在appstore / googleplay上下载新的移动应用程序，而且我不确定它们是否是最新的。 您能否提供任何指导和良好操作技巧，以使这些升级顺利进行，并且对客户没有风险？ 我需要“版本”的哪个组件？即使客户端不升级其移动应用程序，如何确保一切正常？我应该强迫他升级以简化工作吗？ 简而言之，我应该如何组织才能使我的多面项目随着时间的推移而上线？

14 design  architecture  project-management  deployment  release-management 

我们有一种情况，我必须处理大量涌入服务器的事件，平均每秒大约1000个事件（峰值可能是2000个）。 问题 我们的系统托管在Heroku上，并使用相对昂贵的Heroku Postgres DB，该数据库最多允许500个DB连接。我们使用连接池从服务器连接到数据库。 事件传入的速度快于数据库连接池无法处理的速度 我们遇到的问题是事件的发生速度快于连接池无法处理的速度。到一个连接完成从服务器到DB的网络往返时，它可以释放回池中，而不是n其他事件。 最终，事件堆积起来，等待保存，并且由于池中没有可用的连接，它们超时并且整个系统变得无法运行。 我们已经通过以较慢的速度从客户端发出有问题的高频事件来解决紧急情况，但是我们仍然想知道在需要处理高频事件时如何处理这种情况。 约束条件 其他客户端可能希望同时读取事件 其他客户端连续请求使用特定密钥读取所有事件，即使它们尚未保存在数据库中也是如此。 客户端可以查询GET api/v1/events?clientId=1并获取客户端1发送的所有事件，即使这些事件尚未保存到DB中也是如此。 是否有有关如何处理此问题的“教室”示例？ 可能的解决方案 使事件排队在我们的服务器上 我们可以在服务器上排队事件（队列的最大并发性为400，因此连接池不会用完）。 这是个坏主意，因为： 它将耗尽可用的服务器内存。堆积的排队事件将消耗大量RAM。 我们的服务器每24小时重启一次。这是Heroku施加的硬限制。当事件排队时，服务器可以重新启动，导致我们丢失排队的事件。 它在服务器上引入状态，从而损害了可伸缩性。如果我们有一个多服务器设置，并且客户端要读取所有已排队+保存的事件，则我们将不知道已排队事件在哪台服务器上。 使用单独的消息队列 我假设我们可以使用消息队列（例如RabbitMQ吗？），在其中将消息泵入其中，另一方面，还有另一台服务器仅处理将事件保存在DB上。 我不确定消息队列是否允许查询排队的事件（尚未保存），因此，如果另一个客户端想要读取另一个客户端的消息，我只能从数据库中获取已保存的消息，并从队列中获取待处理的消息。并将它们连接在一起，这样我就可以将它们发送回读取请求客户端。 使用多个数据库，每个数据库使用中央数据库协调器服务器保存一部分消息，以管理它们 不过，我们的另一个解决方案是使用多个数据库，并使用一个中央“ DB协调器/负载平衡器”。接收到事件后，此协调器将选择一个数据库来写入消息。这应该允许我们使用多个Heroku数据库，从而将连接限制提高到500 x数据库数。 在进行读取查询时，此协调器可以SELECT向每个数据库发出查询，合并所有结果，然后将其发送回请求读取的客户端。 这是个坏主意，因为： 这个主意听起来像是...太设计了吗？管理（备份等）也将是一场噩梦。它的构建和维护非常复杂，除非绝对必要，否则听起来像是违反了KISS。 它牺牲了一致性。如果我们遵循这个想法，那么跨多个数据库进行事务是不可行的。

13 architecture  performance  scalability  event-sourcing 

这个问题是不言而喻的，只是增加了我的想法： 据我所读，Clean arch中的表示层与MVP中的MV具有相同的职责。 一个人如何决定选择一种模式而不是另一种？

13 architecture  mvp 

让我们从一个例子开始。 比方说，我有一个称为方法export，该方法在很大程度上取决于数据库架构。“严重依赖”是指我知道（经常）向特定表中添加新列会导致相应的export方法更改（通常也应将新字段也添加到导出数据中）。 程序员通常会忘记更改export方法，因为还不清楚您是否应该看一下。我的目标是迫使程序员明确决定是否要忘记查看该export方法还是只是不想在导出数据中添加字段。我正在寻找针对此问题的设计解决方案。 我有两个想法，但它们都有缺陷。 智能的“阅读所有”包装 我可以创建智能包装器，以确保显式读取所有数据。 像这样： def export(): checker = AllReadChecker.new(table_row) name = checker.get('name') surname = checker.get('surname') checker.ignore('age') # explicitly ignore the "age" field result = [name, surname] # or whatever checker.check_now() # check all is read return result 因此，checker断言if是否table_row包含另一个未读取的字段。但是，所有这些东西看起来有点沉重，并且（可能）会影响性能。 “检查该方法”单元测试 我可以创建一个能够记住最后一个表模式的单元测试，并且每次更改表时都会失败。在那种情况下，程序员会看到类似“不要忘了检查export方法”的信息。要隐藏警告程序员，可以（或不会-这是一个问题）签出export并手动（这是另一个问题）通过在其中添加新字段来修复测试。 我还有其他一些想法，但是它们太难实现或难以理解（我不希望该项目成为难题）。 上面的问题只是我不时遇到的更多问题的一个示例。我想绑定一些代码和/或基础结构，因此更改其中的一个代码会立即提醒程序员检查另一个代码和/或基础结构。通常，您有一些简单的工具，例如提取通用逻辑或编写可靠的单元测试，但是我正在寻找更复杂情况的工具：也许我现在知道一些设计模式。

13 design  design-patterns  architecture  unit-testing 

我有一部分使用S＃arp Architecture实施的CQRS模式，如下所示： public class MyCommand { public CustomerId { get; set; } // some other fields } public class MyCommandHandler<MyCommand> : ICommandHandler<MyCommand, CommandResult> { Handle(MyCommand command) { // some code for saving Customer entity return CommandResult.Success; } } 我想知道为什么不只Command包含数据和处理方法的类？这是一种可测试性的好处，您需要与命令属性分开测试命令处理逻辑吗？还是某些频繁的业务需求，您需要由不同的实现来处理一个命令ICommandHandler<MyCommand, CommandResult>？

13 c#  design-patterns  architecture  cqrs 

我在两个月前加入了六个开发团队。人很好，一切都很好。但是越来越多的我观察到一种特别的心态。东西很快就被修复了，但以将来的可用性为代价，几乎没有测试，两个人高兴地承认，他们喜欢把知识带到脑海中，而不是写下来。 该如何处理？我想以身作则，但时间有限-我喜欢架构和实际实现这些东西。但是我担心，临时的心态会感染我，而不是在设计和代码上力求清晰，简单（这并不容易建立），我被无休止的黑客循环激化了-这没有局外人可以解耦-仅出于进度和管理的考虑。

13 architecture  coding-style  management  technical-debt 

这个问题是关于架构的最佳实践。 我们目前的架构 我有一个PHP类，可访问MySQL获取用户信息。叫它User。 User可以多次访问，因此我们实现了缓存层以减少负载。 第一层是我们所谓的“每个请求”缓存。从MySQL检索数据后，我们将数据存储在的私有属性中User。任何后续的数据请求都返回该属性，而不是从MySQL重新请求数据。 由于Web请求是根据每个请求生存和终止的，因此此缓存仅阻止应用程序在单个请求中多次访问MySQL。 我们的第二层是Memcached。当私有属性为空时，我们首先检查Memcached中的数据。如果Memcached为空，我们向MySQL查询数据，更新Memcached，然后更新的private属性User。 问题 我们的应用程序是一个游戏，有时必须使某些数据尽可能最新。在大约五分钟的时间内，对用户数据的读取请求可能会发生10到11次；那么可能会发生更新。随后的读取请求必须是最新的，否则游戏机制将失败。 因此，我们要做的是实现在数据库更新发生时执行的一段代码。此代码使用更新的数据在Memcached中设置密钥，因此所有后续对Memcached的请求都是最新的。 这是最优的吗？在尝试维护此类“活动缓存”时，是否应注意性能问题或其他“陷阱”？

13 architecture  caching  memcached 

我现在有一些基于Web的大型多租户产品，很快我就会发现会有很多针对租户的自定义设置。 这里或那里的额外字段，可能是工作流程中间的额外页面或某些额外的逻辑-诸如此类。 其中一些自定义项可以纳入核心产品，这很棒。其中一些是非常具体的，并且会妨碍其他人。 我有一些想法可以解决这个问题，但是似乎没有一个很好的扩展。显而易见的解决方案是引入大量的客户端级别设置，从而允许基于每个客户端启用各种“功能”。这样做的缺点当然是庞大的复杂性和混乱性。您可能会引入大量的设置，并且随着时间的流逝，各种类型的逻辑（演示，业务）可能会失控。然后是特定于客户的字段的问题，这比起在现有表中添加一堆可以为空的字段来讨价还价。 那么人们在做什么来管理呢？Force.com似乎是可扩展性的主人。显然，他们已经从头开始创建了一个超级可扩展的平台。您可以使用其基于Web的用户界面添加几乎所有内容。FogBugz做了一些类似的事情，他们创建了一个健壮的插件模型，考虑到它，可能实际上是受Force启发的。我知道他们在上面花了很多时间和金钱，如果我没记错的话，目的是在内部实际使用它来进行未来的产品开发。 听起来像我可能会尝试构建的那种东西，但可能不应该这样做。:) 在可插拔架构上进行大量投资是唯一的方法吗？您如何处理这些问题，并且看到了什么样的结果？ 编辑：看起来FogBugz确实通过构建一个相当健壮的平台，然后使用它来组装屏幕来解决了该问题。要扩展它，您将创建一个包含实现ISearchScreenGridColumn之类的接口的类的DLL，该DLL成为一个模块。考虑到他们拥有大量的开发人员，并且他们从事了几个月的开发工作，我确信构建起来非常昂贵，而且它们的表面积可能是我应用程序大小的5％。 现在，我很想知道Force.com是否是处理此问题的正确方法。我是ASP.Net的核心人物，所以这是一个很奇怪的职位。

13 asp.net  plugins  architecture