Questions tagged «architecture»

我正在使用Zend Framework 1和Doctrine2作为ORM层在PHP中构建应用程序。一切进展顺利。现在，我偶然发现ZF1和Doctrine2都附带并依赖于它们自己的缓存实现。我对两者都进行了评估，虽然每个人都有自己的优点和缺点，但就我的简单需求而言，它们都不比其他人优越。这两个库似乎都是针对各自的接口而不是针对其实现编写的。 我之所以认为这是一个问题，是因为在应用程序的引导过程中，我必须配置两个缓存驱动程序-每个都有自己的语法。这样很容易造成不匹配，因此，与缓存后端建立两个连接的效率很低。 我正在尝试确定最佳的前进方式，并欢迎您可能提供的任何见解。 到目前为止，我想到的是四个选择： 不执行任何操作，请接受存在两个提供缓存功能的类。 创建一个Facade类，将Zend的接口粘贴到Doctrine的缓存实现上。 选项2的另一种方法-创建一个Facade，以在Zend Framework后端上映射Doctrine的界面。 使用多接口继承创建一个接口来统治所有接口，并祈祷不存在任何重叠（即：如果两个都有“保存”方法，由于PHP的原因，它们将需要以相同的顺序接受参数）缺乏适当的多态性）。 哪个选项是最佳选择，或者我不知道有没有“以上所述”变体？

9 php  architecture  third-party-libraries  polymorphism 

我记得学习VB4并将一个按钮拖动到窗体上，双击该按钮，然后在刚刚被我神奇地祝福的事件处理程序中键入代码。来自QBASIC，我为“ VB”中的“ V”而感到激动，这是自切面包以来最好的视觉设计师。 当然，您可以通过编程方式完成所有这些操作，但是“ V”的魔力是如此吸引人，您只能忍不住拖动该按钮。我们被鼓励走那条路。 但是几年前，我开始学习C＃和.net框架，并且对我以为我知道的一切刚刚消失的方式着迷。VB6中发生了很多神奇的事情，.net完全揭开了它的神秘面纱：以构造函数和InitializeComponents方法为例。在后者中，您将找到从工具箱中拖动的所有控件实例，已注册的所有事件以及在设计器中设置的属性。 很好...我想。只是，我感觉我不“拥有”正在发生的事情，我只能通过设计者修改的这段代码使我烦恼不已。每次将一个表示“确定”的按钮从一种形式复制到另一种形式（有时连同其兄弟“取消”）时，您实际上是在复制代码，这是一种罪过吗？教皇说，干，别重复。 除了客观存在的宗教和思想流派之外，我们是否不应该从基本表单中获取表单，并让“确定”按钮（及其所有朋友）都在基本表单上生活？像a这样的东西FormBase衍生出a DialogFormBase; 立即创建所有类...通过键入代码。根据实例的类的创建方式创建按钮（即，构造函数的enum参数确定要创建的按钮），将控件布置在拆分面板和流布局面板的内部，并按如下方式插入表单Content适用于主要内容面板。这不是ASP.net对母版页和内容占位符的作用吗？当我需要一个新的“母版页”时，我会派生一个表单，但是这个新的“母版页”仍然派生自基本表单类，因此整个应用程序的视觉效果是一致的。 对我来说，这是很多更多的代码重用比什么都重要，我曾经在的WinForms设计师做的，它甚至不是辛苦，代码不与200线方法混乱，我无法控制，我可以将评论放在我喜欢的位置，它们不会被设计师覆盖。我想这只是模式和体系结构的问题，这就是带我进入此链接的地方：能够共享通用功能的Windows窗体的最佳设计，我在那里发现，除了那里的答案外，我确切地表明了我的意思。这样做，但它建议对形式的继承，因为设计师的考虑。那是我不了解的部分。出于代码结构方面的考虑，尤其是在形式和控件继承方面，我认为没有理由要避免，除非这样做会破坏设计人员。 我们不能都只是懒惰，所以我缺少哪一部分？

9 architecture  winforms  designer 

我在域驱动设计中的表示层和应用程序层之间划清界限时遇到麻烦。 控制器，视图，布局，Javascript和CSS文件应该放在哪里？ 是在应用程序层还是表示层中？ 如果它们都放在同一层，那么包含另一层的是什么？是空的吗？

9 architecture  domain-driven-design  layers 

最近，我对软件开发中的敏捷实践产生了兴趣，从那以后，我已经看到很多文章指出，这些实践可以降低总体成本。 其背后的逻辑通常是这样的：如果您的需求发生变化，则可以在下一个sprint待办事项列表中反映此变化，这将导致成本降低，因为设计新功能并在时间上紧密地实现了新功能，因此根据著名的规则，成本降低了，您越晚需要对需求进行更改，满足该需求的成本就越高。 但是中大型软件项目很复杂。需求的突然变化并不意味着您不必接触系统的其他部分即可满足该需求。在很多情况下，将需要对架构进行非常大的修改，这也意味着您将需要重新实现依赖于较旧架构的所有功能。因此，降低成本的要点在这里已经消失了。当然，如果新的需求需要系统的新的独立部分，那不是问题，旧的体系结构只会不断增长，不需要重新考虑和重新实现。 相反。如果您使用的是瀑布，但突然意识到必须引入新的要求，则可以进行更改。如果需要更改现有体系结构，则可以重新设计它。如果它并没有真正引起混乱，而只是引入了系统的新部分，那么您就去做所有的工作，在这里没有问题。 话虽如此，在我看来，敏捷开发的唯一优势是可以在sprint之间完成功能的完整构建，对于很多人和项目来说，这并不关键。此外，敏捷似乎会导致整个软件体系结构不佳，因为某种功能会相互重叠，因此敏捷团队只关心功能的工作原理，而不是功能的工作原理。看起来，当系统随着时间的推移而变得越来越复杂时，敏捷开发实践实际上会增加整个产品架构的混乱度，从而最终导致更高的成本，因为引入变更的难度越来越大，而瀑布式设计则可以使您完善架构在释放任何东西之前。 有人可以指出我在哪里出问题了吗，因为显然很多人在生产环境中使用敏捷，所以我一定在某个地方错了。

9 project-management  architecture  agile 

我正在开发Silverlight应用程序。我将其拆分为几个程序集： 域 存储库（所有保存到Sterling数据库的东西） 用户界面 ... 这就是我学到的方法，但我想知道。如果您知道这些DLL将不会被重用，是否有必要将它们拆分？还是可以将所有内容放在一个程序集中并使用文件夹和命名空间来保持整洁？ 我也看到过有太多程序集的项目。而不是在适当的地方使用名称空间。 那么：什么时候为一些新代码创建新程序集？关于这个主题有什么好的资源吗？您是否在技术上（域，数据，UI等）和/或功能上（例如，患者管理，患者医疗，医院后勤……等）拆分了代码？可能仅适用于大型企业级应用程序？

9 .net  architecture  visual-studio  code-organization 

背景 本地数据库包含近13亿个唯一行。每行都与特定的纬度和经度（位置）间接相关。每行都有一个日期戳。 用例 问题如下： 用户设置开始/结束日期以及值的范围（例如100到105）。 系统将按位置分组与给定日期匹配的所有行。 系统执行确定在那些日期期间具有落入给定值范围的统计可能性的位置。 系统向用户显示所有匹配的位置。 这是速度和规模的问题。 题 您能想到哪一种最便宜的解决方案体系结构可使这种系统在五秒钟内为用户检索结果？ 当前系统 当前环境是： PostgreSQL 8.4（可以升级；不能选择切换数据库） R和PL / R XFS文件 WD VelociRaptor 8 GB RAM（Corsair G.Skill; 1.3 GHz） 四核原装Intel 7（2.8 GHz） Ubuntu 10.10 可以接受硬件升级。 更新-数据库结构 表中的数十亿行类似于： id | taken | location_id | category | value1 | value2 | value3 id-主键 采取-分配给行的日期 …

9 architecture  database  geospatial 

我熟悉架构评估方法，例如技术架构权衡分析方法（ATAM）和面向业务的成本效益分析方法（CBAM）。但是，这些方法的规模相当大：它们规定了一些集思广益的会议，演示文稿，开发了许多描述折衷方案的方案等。尽管对于一定规模的项目很有用，但对于通常用于内部项目或桌面应用程序的项目却太大了由少数开发人员（或更少）开发的产品，即使它们很小，也有一些相当严格的质量约束（性能，可伸缩性，适应性）。 我过去使用的一种典型做法是让一名开发人员（或者如果一个团队有一个团队，则由架构师）提出应用程序的通用体系结构，然后与其他团队在白板上进行讨论，通常使用一些易于绘制和理解的伪UML表示法。这通常会导致反馈和体系结构上的某些迭代。但这往往过于非正式化，导致做出各种假设，这些假设后来可能变成错误的决定。 像ATAM方法通常迫使所有利益相关者深入思考的架构，直到每个人都至少在什么架构究竟同意导致讨论的。 有没有人有进行轻量级前期架构评估的经验？如果是这样，有什么好的做法？

9 architecture  evaluation 

“规范”思想在软件中无处不在。诸如Canonical Model，Canonical Schema，Canonical Data Model等模式似乎在开发中一次又一次出现。 像许多开发人员一样，我经常不加批判地遵循传统的常识，即需要规范的模型，否则您将面对映射器和翻译器的组合爆炸。或者至少，我用来做，直到几年前，当我第一次读到了几分臭名昭著的不信任投票EF： 曾经支持追求规范数据模型的假设既没有也不可能包含一旦将想法付诸实践就会发现的因素。通过多年的反复试验，我们发现针对每个单独的上下文使用单独的模型（可能在其中使用规范的数据模型）是最简单的方法，也是成本最低的方法，并且可以带来更大的可维护性和可扩展性使用上下文模型的应用程序和端点，并且这种方法不会像规范模型那样鼓励软件熵。 这篇文章没有提供任何证据来支持其主张，但是确实让我质疑CDM方法足够长的时间以尝试替代方法，并且所产生的软件在字面上或形象上都没有爆炸。但这并不意味着要孤立很多。我本来可以很幸运。 因此，我想知道，是否对软件系统或体系结构中的规范模型与上下文模型的实际，长期影响进行了认真的研究？ 或者，如果现在提出这个要求还为时过早，那么有没有任何开发人员/架构师撰写过有关从CDM切换到独立上下文模型（反之亦然）的个人经验的书，以及对生产率，复杂性或可靠性等方面的实际影响是什么？ 那么在不同级别上的差异又如何呢？也就是说，在单个应用程序中使用同一模型与在应用程序系统或整个企业中使用模型之间的差异呢？ （请只提供事实；欢迎战争故事，但不能no测。）

9 design-patterns  architecture  data  domain-model 

我们的团队最初由大多数服务器端开发人员组成，他们只具备Javascript方面的最少专业知识。在ASP.NET中，我们过去经常在代码背后或通过MVC中的控制器编写许多UI逻辑。 不久前，有2位高级客户端开发人员加入了我们的团队。他们可以在HTMl / CSS / Javascript中完成我们以前使用服务器端代码和服务器端Web控件可以做的几乎所有事情： 显示/隐藏控件 做验证 控制AJAX刷新 因此，我开始认为，围绕我们的业务逻辑创建一个高级API可能会更有效，例如Amazon Fulfillment API：http : //docs.amazonwebservices.com/fws/latest/APIReference/，以便该客户端端开发人员将完全接管UI，而服务器端开发人员将仅专注于业务逻辑。 因此，对于订购系统，您将拥有一个高级API，例如： OrderService.asmx CreateOrderResponse CreateOrder(CreateOrderRequest) AddOrderItem AddPayment - SubmitPayment - GetOrderByID FindOrdersByCriteria ... 可以通过JSON / REST访问API，因此很容易从客户端UI中使用。我们可以使用此API进行内部UI开发，也可以让第三方使用此API创建自己的应用程序。 随着Javascript的发展以及优秀的客户端开发人员的可用性，现在是否是摆脱代码隐藏/控制器并仅专注于开发客户端开发人员可以使用的高级API（阿拉玛）的好时机？

9 javascript  architecture  asp.net  team  enterprise-architecture 

背景 我目前正在针对MS Office插件自动化一些测试。我们将在VS 2010中创建编码的UI测试。我想我可以使用“ 编码的UI测试生成器 ”工具，但它实际上并不适合我的特定情况。 因此，我为每个UI控件/映射创建了自己的UI Map类和扩展方法，在其中添加了不同的操作功能。例如，按下按钮或声明一些UI值。 测试用例的场景在测试类中。 我是这个领域的新手，也是自动化测试员的新手。 问题 人们是否愿意从编程/设计的角度分享经验和对台式机应用程序测试自动化的一些好的实践建议？

9 programming-practices  testing  architecture