Questions tagged «design»

有关通过软件设计解决问题和计划解决方案的问题。

18
您要优化什么?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 6年前关闭。 一般来说,在设计软件时,您通常倾向于哪种类型的优化? 您是喜欢优化设计的人吗? 开发时间(即快速编写和/或易于维护)? 处理时间 存储空间(RAM,DB,光盘等) 当然,这很大程度上取决于要解决的问题的类型以及所涉及的期限,因此,我想听听导致您选择一种优化形式而不是另一种优化形式的原因。

6
什么时候应该使用存储过程?
如果我将所有业务逻辑都包含在代码中并使用Entity Framework,那么在什么情况下(如果有),将某些业务逻辑移至存储过程中而不是将其全部保留在代码中会更好吗? 需要明确的是,我的意思是与当前设置(代码中的业务逻辑)结合使用,而不是与其结合使用。我已经看到了许多类似的问题,这些问题都要求在存储过程中拥有所有业务逻辑的利弊,但是对于保留少量使用边缘过程逻辑的同时保留其余业务逻辑的情况,我没有发现太多的益处在代码中。 如果有所作为,我正在使用MSSQL和Entity Framework。 在以下情况下,我曾使用过存储过程: 一份复杂的报告需要几分钟才能运行(这是Web应用程序中的页面)。我发现我可以编写比LINQ提供的SQL更有效的SQL(只需花费几秒钟即可运行)。 一个Web应用程序需要读写一个单独数据库中的几个表,其中包含许多其他与该应用程序无关的敏感信息。我没有给它访问所有内容的权限,而是使用了一个存储过程,该过程仅执行所需的操作,并且仅返回有限的信息。然后,可以只给Web应用程序访问此存储过程的权限,而不能访问任何表等。 在问这个问题之前,我查看了其他帖子: 存储过程是全球最大的IT软件咨询公司之一的不良做法? 在Web应用程序的存储过程中保存所有业务逻辑的利弊 /programming/15142/what-are-the-pros-and-cons-to-keeping-sql-in-stored-procs-versus-code /dba/2450/what-are-the-arguments-against-or-for-putting-application-logic-in-the-database/2452#2452 什么时候不使用ORM而更喜欢存储过程?

6
在电子商务网站中将并发管理到篮子的最佳实践
管理两个客户同时添加库存仅为1个产品的情况的最佳实践是什么? 必须在购物篮的代码中进行检查,以避免这2个客户之一添加相同的产品? 还是必须在付款阶段执行此检查,例如进行第二次查询以确认相关产品仍在库存中(即并发客户尚未购买的产品)?

4
为什么大多数语言都提供最小堆而不是最大堆实现?
我只是注意到了什么,我想知道是否有任何原因。除了C ++(std :: priority_queue是最大堆)之外,我不知道其他提供最大堆的语言。 Python的heapq模块在列表顶部实现了一个二进制min-heap。 Java的库包含一个PriorityQueue类,该类实现了一个最小优先级队列。 Go的库包含一个container / heap模块,该模块在任何兼容的数据结构之上实现了min-heap。 苹果公司的Core Foundation框架包含一个CFBinaryHeap结构,该结构实现了最小堆。 我发现最大堆比最小堆更直观,而且从技术上讲,我认为实现差异只是更改比较运算符的问题。有什么真正的原因吗?大多数应用程序需要最小而不是最大堆吗?提前致谢

7
关于UML,需要了解哪些基本知识?
想要改善这篇文章吗?提供此问题的详细答案,包括引文和答案正确的解释。答案不够详细的答案可能会被编辑或删除。 我希望我对程序设计和行为的涂鸦变得更加精简,并与其他开发人员有共同的语言。 我查看了UML,从原则上讲,这似乎是我想要的东西,但这似乎有些过分。我在网上找到的信息似乎也很and肿且学术性强。 我如何以通俗易懂的方式理解UML,足以向同事解释?在基础层面上了解UML的规范资源是什么?
18 design  uml 

15
使用高级语言进行原型制作常见吗?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 我目前正在玩一个项目,该项目的语言远远超出了我目前的编程能力,而我在(C)中没有多少实际经验,我正在玩这个想法。使用我更熟悉的高级语言(例如Perl / Python / Ruby / C#)进行原型设计是否有价值,以便使整体设计顺利进行? 最终,最终产品是性能敏感的(它是一个数据库引擎),因此选择了C。但是,恐怕不太了解C会让我迷失森林。 在寻找类似问题时,我注意到一个人提到程序员曾经在Prolog中进行原型设计,然后在汇编器中进行原型设计。

2
函数式程序员使用什么代替UML?
我是CS学生。我目前正在参加讲座,在那里我们将学习目标分析和设计。它主要由编写用例,分析我们为客户编写一些应用程序时可能遇到的问题以及如何设计项目以使其既可扩展,对开发人员清晰又不会在客户争论某些问题时产生问题而组成特征。由于它是“客观的”,因此我们是从OOP(类等)的角度来学习它的。 现在,我们使用UML作为帮助工具。我相信我对OOP有很好的了解,但是我也学习了功能范例,并在我的一些较小的项目中成功使用了它。 我们的老师面对“功能范式有什么意义”?问题,他回答他没有使用功能语言编写任何更大的项目,并且他不知道功能程序可以使用哪种工具。 那么,他们将使用什么呢?有一些方法吗?或者也许不需要这种东西?

4
如何可视化物理引擎的设计?
我正在开发一个物理引擎,使其很难跟踪整个过程。通常,当我在休息后返回代码时,我只是不记得为什么它不起作用。大多数问题不是简单的编程错误,而是我的物理引擎中的设计缺陷。这就是为什么我应该在编程之前完成设计。 但是,我需要一种方法在纸上书写物理引擎的整个设计。否则,明天我会忘记它,然后再次迷路。UML类图根本不适用于物理引擎的设计。我不是很在乎课程,而是在过程。我认为业务流程图不是真正有用的,因为对流程的单个步骤(框架)进行建模不会帮助我了解引擎在许多步骤上的最终行为。 那么,应该使用哪种图表来帮助我跟踪流程?专业人士使用哪种图表制作物理引擎?

3
在RESTful API中处理令牌更新/会话到期
我正在构建一个使用JWT令牌进行用户身份验证的RESTful API(由login端点发出,然后在所有标头中发送),并且需要在固定时间后刷新令牌(调用renew端点,该端点将返回更新的令牌) )。 用户的API会话有可能在令牌到期之前变得无效,因此我的所有端点都首先检查以下各项:1)令牌仍然有效,以及2)用户会话仍然有效。由于客户端将令牌存储在本地,因此无法直接使令牌无效。 因此,我所有的端点必须向我的客户发出两种可能情况的信号:1)是时候续订令牌了; 2)会话已变为无效,并且不再允许它们访问系统。我可以想到两种替代方法,当两种情况之一发生时,我的端点可以向其客户端发出信号(假设客户端可以适应任一选项): 如果会话无效,则返回http 401代码(未经授权),或者在令牌到期且需要调用renew端点时返回412代码(前提条件失败),这将返回200(正常)代码。 返回401,表示会话无效或令牌已过期。在这种情况下,客户端将立即调用该renew端点,如果它返回200,则刷新令牌,但是如果renew还返回401,则意味着该客户端不在系统之外。 您会推荐上述两种选择中的哪一种?哪一个会更标准,更容易理解和/或更RESTful?还是您会建议完全不同的方法?您发现这两种选择有明显的问题或安全隐患吗?如果您的答案包括支持您的观点的外部参考,则可以加分。 更新 伙计们,请关注一个真正的问题- 表示续订/会话无效的两个http代码替代方案中哪一个最好?不要介意我的系统使用JWT 和服务器端会话的事实,这是我的API针对非常特定的业务规则的特性,而不是我正在寻求帮助的部分;)

4
如何存储只读数据以与应用程序一起部署?
我正在开发一个桌面应用程序,此应用程序需要运行一些信息,但不会更改任何这些信息(必须在应用程序的每次执行中加载数据,但永远不要更改数据)。数据必须与应用程序运行时存储在同一台计算机上(客户端存储吗?)。 如果用户不能轻易更改此信息(假设他们没有太多的IT知识),那也更好。 我应该如何存储这种信息?本地数据库?与应用程序一起发送的XML? 我正在使用WPF。
17 c#  design  data  wpf 

2
最小惊讶原理(POLA)和界面
25年前,当我学习C ++时,我被教导说接口应该是宽容的,并且尽可能不在乎方法的调用顺序,因为消费者可能无法访问源代码或文档来代替这个。 但是,每当我指导初级程序员和高级开发人员听到我的消息时,他们都会惊讶地做出反应,这让我怀疑这是否真的是一件事情,或者它是否已经过时了。 像泥一样清澈? 考虑具有以下方法的接口(用于创建数据文件): OpenFile SetHeaderString WriteDataLine SetTrailerString CloseFile 现在,您当然可以按顺序浏览这些文件,但是说您不关心文件名(认为a.out)或包括什么标题和尾部字符串,您可以致电AddDataLine。 一个不太极端的示例可能是省略标题和结尾。 还有一种可能是在打开文件之前设置标题和结尾字符串。 这是公认的接口设计原则,还是只是在命名之前采用POLA方式? 注意:不要被这个界面的细节所困扰,这仅仅是一个例子。

2
事件源和REST
我遇到了事件源设计,我想在需要REST客户端(准确地说是RESTful)的应用程序中使用。但是,由于REST非常像CRUD,并且事件源基于任务,因此我无法将它们连接在一起。我想知道您如何设计基于对REST服务器的请求的命令创建。考虑以下示例: 借助REST,您可以将一个新状态放入名为File的资源中。在一个请求中,您可以发送新的文件名,可以更改父文件夹和/或更改文件的所有者,依此类推。 如何构造服务器,以便可以使用事件源。我在考虑这些可能性: 确定服务器上哪些字段被改变,并创建相应的命令(RenameFileCommand,MoveFileCommand,ChangeOwnerCommand,...)并单独派遣这些。但是,在这种设置中,每个命令都可能失败,从而使其他命令无法进行事务处理,从而无法进行资源的“原子”更改。 调度只需要一个命令(UpdateFileCommand),并在命令处理程序,更精确地在总量上,确定哪些领域发生了变化,并发送单个事件,而不是(FileRenamedEvent,FileMovedEvent,OwnerChangedEvent,...) 我一点都不喜欢这个命令:在对服务器的请求中,我会在标头中指定要使用的命令,因为UI仍基于任务(但通信是通过REST完成的)。但是,在REST通信的任何其他用途(例如,外部应用程序)中,它都将失败,因为它们不一定要仅更改一个请求中的一个字段。另外,我在UI,REST和基于ES的后端中引入了很大的结合。 您更喜欢哪一个,或者有更好的方法来解决这一问题? 旁注:使用Java和Axon Framework编写的用于事件源的应用程序。

5
不知道总数的百分比算法
假设有n热线电话。 每当客户致电热线时,该呼叫就会被转接到其中一条n线路。我想将呼叫百分比分配给n行中的每行。假设有两条线路,一条线路分配了60%,另一条线路分配了40%,呼叫总数为10,因此第一行将收到6个呼叫,第二行将收到4个呼叫。 我知道提前拨打每条线路的百分比,但是问题是我不知道一天会收到多少次电话。 如何在不知道总呼叫数的情况下分配呼叫数?

9
用于访问计量单位的数据结构
TL; DR-我正在尝试设计一种最佳的数据结构,以定义度量单位内的单位。 A Unit of measure本质上是value与关联的(或数量)unit。 SI单位有七个基准或尺寸。即:长度,质量,时间,电流,温度,物质量(摩尔)和发光强度。 这足够简单,但是我们经常使用许多派生单位和费率。示例组合单位为牛顿:kg * m / s^2示例比率为tons / hr。 我们的应用程序严重依赖隐含单位。我们将把单元嵌入变量或列名中。但这在我们需要指定具有不同单位的度量单位时会产生问题。是的,我们可以在输入和显示时转换值,但这会生成很多开销代码,我们希望将其封装在自己的类中。 在Codeplex和其他协作环境上有许多解决方案。项目的许可是可以接受的,但是项目本身通常最终会变得太轻或太重。我们正在追逐自己的“正当”独角兽。 理想情况下,我可以使用以下方法定义新的度量单位: UOM myUom1 =新的UOM(10伏); UOM myUom2 =新的UOM(43.2,牛顿); 当然,我们会根据客户的需求混合使用英制和SI单位。 我们还需要使这种单位结构与将来的数据库表保持同步,以便我们也可以在数据中提供相同程度的一致性。 定义创建计量单位类别所需的单位,派生单位和费率的最佳方法是什么?我可以看到使用了一个或多个枚举,但这对于其他开发人员可能会感到沮丧。一个单一的枚举包含200多个条目,将是巨大的,而基于SI与英制单位的多个枚举可能会造成混淆,而基于单位本身的分类的其他细分可能会造成混淆。 枚举示例显示了我的一些担忧: myUnits.Volt myUnits.Newton myUnits.meter SIUnit.meter ImpUnit.foot DrvdUnit.Newton DrvdUnitSI.Newton DrvdUnitImp.FtLbs 我们正在使用的单位集非常明确,而且空间有限。当我们有客户需求时,我们确实需要能够扩展和添加新的派生单位或费率。尽管我认为更广泛的设计方面适用于多种语言,但是该项目使用C#。 我看过的一个库允许通过字符串自由输入单位。然后,他们的UOM类解析该字符串,并相应地添加内容。这种方法的挑战在于,它迫使开发人员思考并记住正确的字符串格式是什么。如果我们不在代码内添加其他检查以验证在构造函数中传递的字符串,则会冒运行时错误/异常的风险。 实质上,另一个库创建了太多开发人员必须使用的类。随着等效值单位它提供了一个DerivedUnit和RateUnit等。本质上,对于我们要解决的问题,代码过于复杂。该库实际上允许任何组合(在单位世界中是合法的),但是我们很高兴通过不允许所有可能的组合来扩大问题范围(简化代码)。 其他库非常简单,甚至都没有考虑过运算符重载。 另外,我也不担心尝试进行错误的转换(例如:伏特到米)。开发人员是目前唯一可以在此级别访问的人员,我们不一定需要防止这些类型的错误。

5
如何减轻运行时创建视图模型的痛苦
对于这个很长的问题,我深表歉意。我在下面总结了我的问题 在MVC世界中,事情很简单。该模型具有状态,在视图显示模式,并且控制器不东西/与模型(基本上),控制器没有的状态。为了完成这些工作,Controller对Web服务,存储库等有一些依赖性。实例化控制器时,您关心的是提供那些依赖关系,而没有别的。执行动作(Controller上的方法)时,可以使用这些依赖关系来检索或更新Model或调用某些其他域服务。如果存在任何上下文,例如说某些用户想要查看特定项目的详细信息,则将该项目的ID作为参数传递给Action。Controller中的任何地方都没有对任何状态的引用。到目前为止,一切都很好。 输入MVVM。我爱WPF,我喜欢数据绑定。我喜欢使数据绑定到ViewModels更加容易的框架(使用Caliburn Micro atm)。我觉得这个世界上事情并不那么简单。让我们再次做运动:该模型具有状态下,查看显示的视图模型和视图模型做的东西/使用模型(基本),一个视图模型做有状态!(澄清;也许它代表所有属性的一个或多个模型,但是这意味着它必须具有对模型的一种方式或另一种,这本身就是状态的基准)为了做ViewModel在Web服务,存储库等方面有一些依赖性。实例化ViewModel时,您关心的是提供那些依赖关系,还需要提供状态。女士们,先生们,这无休止地困扰着我。 每当您需要从中实例化a ProductDetailsViewModel时ProductSearchViewModel(您又从中实例化了ProductSearchWebServicewhich IEnumerable<ProductDTO>,每个人还和我在一起吗?),您可以执行以下操作之一: call new ProductDetailsViewModel(productDTO, _shoppingCartWebService /* dependcy */);,这很糟糕,想象另外3个依赖关系,这意味着也ProductSearchViewModel需要承担这些依赖关系。改变构造函数也是很痛苦的。 调用_myInjectedProductDetailsViewModelFactory.Create().Initialize(productDTO);,工厂只是一个Func,大多数IoC框架很容易生成它们。我认为这很糟糕,因为Init方法是一个泄漏的抽象。您也不能对Init方法中设置的字段使用readonly关键字。我确定还有更多原因。 呼叫_myInjectedProductDetailsViewModelAbstractFactory.Create(productDTO);So ...这是通常建议用于此类问题的模式(抽象工厂)。我虽然是个天才,但它满足了我对静态类型的渴望,直到我真正开始使用它为止。我认为样板代码太多了(除了我使用的荒谬变量名之外,您都知道)。对于每个需要运行时参数的ViewModel,您将获得两个额外的文件(工厂接口和实现),并且需要键入非运行时依赖项,例如额外输入4次。而且,每次依赖关系发生变化时,您也需要在工厂中进行更改。感觉我什至不再使用DI容器。(我认为温莎城堡对此有某种解决方案(有其自身的缺点,如果我错了,请纠正我))。 用匿名类型或字典来做某事。我喜欢我的静态打字。 是的。以这种方式混合状态和行为会产生一个在MVC中根本不存在的问题。我觉得目前还没有一个真正足够的解决方案来解决这个问题。现在,我想观察一些事情: 人们实际上使用了MVVM。因此,他们要么不在乎以上所有内容,要么拥有一些出色的其他解决方案。 我还没有找到带有WPF的MVVM的深入示例。例如,NDDD示例项目极大地帮助我理解了一些DDD概念。如果有人可以将我指向类似MVVM / WPF的方向,我真的很喜欢它。 也许我在做MVVM时出错了,应该将我的设计倒过来。也许我根本不应该有这个问题。好吧,我知道其他人也问过同样的问题,所以我认为我不是唯一的一个。 总结一下 我是否可以正确地得出结论,将ViewModel作为状态和行为的集成点是整个MVVM模式存在某些困难的原因? 使用抽象工厂模式是以静态类型实例化ViewModel的唯一/最佳方法吗? 是否有类似深度参考实现的内容? 是否有很多带有状态/行为的ViewModels设计气味?
17 c#  design  wpf  mvvm 

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.