Questions tagged «silverlight»

Silverlight是Microsoft的跨浏览器,跨平台插件,用于媒体体验和丰富的交互式应用程序。

10
在什么条件下使用MVVM是合适的?
模型视图视图模型是由Microsoft开发的,目标是支持事件驱动编程的UI开发平台,特别是使用XAML和.NET语言的.NET平台上的Windows Presentation Foundation(WPF)和Silverlight。此后的几年中,许多Javascript框架(例如Angular,Knockout和ExtJS)都采用了这种模式。 像大多数软件模式一样,MVVM具有适当的用途和滥用。在什么条件下使用MVVM是合适的?什么时候不明智?

3
谁应该控制MVVM应用程序中的导航?
例1:我的MVVM应用程序中显示了一个视图(出于讨论目的,请使用Silverlight),然后单击一个按钮,该按钮会将我带到新页面。 示例2:同一视图具有另一个按钮,单击该按钮后应在子窗口(对话框)中打开详细信息视图。 我们知道,将有ViewModel公开的Command对象绑定到按钮,这些对象具有响应用户单击的方法。但是,那又如何呢?我们如何完成该动作?即使我们使用所谓的NavigationService,我们在说什么呢? 更具体地说,在传统的“视图优先”模型(如基于URL的导航方案,例如Web或SL内置导航框架)中,Command对象必须知道接下来要显示的视图。当涉及由模式促进的关注点分离时,这似乎越界了。 另一方面,如果未将按钮连接到Command对象,并且其行为类似于超链接,则可以在标记中定义导航规则。但是我们是否希望Views控制应用程序流,并且导航不只是另一种业务逻辑吗?(在某些情况下我可以说是,在其他情况下我可以说不。) 对我来说,MVVM模式的乌托邦式实现(我听说其他人对此表示赞同)将以一种可以使应用程序无头运行(即无视图)的方式连接ViewModel。这为基于代码的测试提供了最大的表面积,并使Views成为应用程序的真实外观。而且我的ViewModel不在乎它是否显示在主窗口,浮动面板或子窗口中,应该吗? 根据这种方法,在运行时由其他机制来“绑定”应该为每个ViewModel显示的视图。但是,如果我们想与多个ViewModel共享一个View,反之亦然呢? 因此,鉴于需要管理View-ViewModel关系,以便我们知道在视图之间导航时需要显示的内容(包括显示子窗口/对话框),我们如何真正在MVVM模式中完成此操作?

17
Silverlight有未来吗?[关闭]
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 6年前关闭。 最近,我阅读了一些有关WPF和Silverlight的发展和历史的文章/博客/评论。在某些论坛中,许多开发人员和用户都批评WPF应用程序的性能(例如Visual Studio 2010)。实际上,与Flash相比,Silverlight的市场份额不是很高。在2010年PDC大会上,鲍勃·穆格里亚(Bob Muglia)表示“我们的Silverlight战略和重点已经转移了……”,微软希望在未来推出HTML5。 此外,微软宣布HTML5是Windows 8和Windows Phone 8(“芒果”)平台的核心部分。 最近,我开始学习Silverlight,现在我必须自问,我是否应该继续花时间学习这些非常好用的强大技术!他们有未来吗?(Windows)桌面(客户端)应用程序有未来吗?所谓的“丰富的Internet应用程序”是否有未来?还是HTML5会成为软件开发中的“绝对真理”? 您对此有何看法?


5
价值转换器会带来更多麻烦吗?
我正在使用需要大量值转换的视图的WPF应用程序。最初,我的哲学(部分是受到有关XAML信徒的激烈辩论的启发)的,我应该严格按照支持视图数据要求的观点来构建视图模型。这意味着将值转换为可见性,画笔,大小等所需的任何值转换都将由值转换器和多值转换器处理。从概念上讲,这似乎很优雅。视图模型和视图都将具有独特的目的并且可以很好地分离。在“数据”和“外观”之间将划清界限。 好吧,在将这种策略赋予“旧的大学尝试”之后,我有些怀疑是否要继续以这种方式发展。我实际上正在强烈考虑转储值转换器,并将(几乎)所有值转换的责任直接交给视图模型。 使用价值转换器的现实似乎并没有达到完全分开的关注点的表观价值。对于价值转换器,我最大的问题是使用它们很乏味。您必须创建一个新类,实现IValueConverter或IMultiValueConverter,将一个或多个值转换为object正确的类型,进行测试DependencyProperty.Unset(至少对于多值转换器而言),编写转换逻辑,在资源字典中注册转换器 [请参见下面的更新],最后,使用相当冗长的XAML(这要求转换器的绑定和名称都使用魔术字符串)来连接转换器[请参见下面的更新]。调试过程也不是一件容易的事,因为错误消息通常是不明确的,尤其是在Visual Studio的设计模式/ Expression Blend中。 这并不是说替代方案(使视图模型负责所有值转换)是一种改进。这很可能是另一面草更绿的问题。除了失去优雅的关注点分离之外,您还必须编写一堆派生属性,并确保RaisePropertyChanged(() => DerivedProperty)在设置基本属性时认真调用,这可能会带来令人不愉快的维护问题。 以下是我汇总的初始清单,这些清单允许视图模型处理转换逻辑并取消使用值转换器的优缺点: 优点: 由于取消了多转换器,因此总绑定数更少 较少的魔术字符串(绑定路径+转换器资源名称) 无需再注册每个转换器(还要维护此列表) 减少编写每个转换器的工作(无需实现接口或强制转换) 可以轻松注入依赖项以帮助进行转换(例如颜色表) XAML标记不那么冗长,更易于阅读 转换器重用仍然可能(尽管需要一些计划) DependencyProperty.Unset没有神秘问题(我在多值转换器中注意到的一个问题) *删除线表示如果您使用标记扩展,这些好处将消失(请参阅下面的更新) 缺点: 视图模型和视图之间的耦合更强(例如,属性必须处理可见性和画笔之类的概念) 更多的总体属性可允许直接映射视图中的每个绑定 RaisePropertyChanged必须为每个派生属性调用(请参阅下面的更新2) 如果转换基于UI元素的属性,则仍必须依赖转换器 因此,正如您可能会说的那样,我对此问题感到非常沮丧。我非常不愿走重构的道路,只是意识到无论我在视图模型中使用值转换器还是暴露大量的值转换属性,编码过程都是同样低效而乏味的。 我是否缺少任何利弊?对于那些尝试了两种价值转换方式的人,您觉得哪种对您更好,为什么?还有其他选择吗?(门徒提到了有关类型描述符提供程序的一些内容,但是我无法理解他们在说什么。对此的任何见解都将受到赞赏。) 更新资料 我今天发现,可以使用一种称为“标记扩展”的东西来消除注册值转换器的需要。实际上,它不仅消除了注册它们的需要,而且还提供了在您键入时选择转换器的智能感知Converter=。这是让我入门的文章:http : //www.wpftutorial.net/ValueConverters.html。 使用标记扩展的能力在上面我的优缺点列表和讨论中(见删除线)在某种程度上改变了平衡。 作为这个启示的结果,我正在尝试一个混合系统,在该系统中,我将转换器用于BoolToVisibility我所说的内容MatchToVisibility,并将视图模型用于所有其他转换。MatchToVisibility基本上是一个转换器,可以让我检查绑定值(通常是枚举)是否与XAML中指定的一个或多个值匹配。 例: Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}" 基本上,这是检查状态为已完成还是已取消。如果是,那么可见性将设置为“可见”。否则,它将设置为“隐藏”。事实证明,这是非常普遍的情况,使用此转换器可以为我节省约15个属性(以及关联的RaisePropertyChanged语句)。请注意,当您键入时Converter={vc:,“ MatchToVisibility”将显示在智能菜单中。这显着减少了出错的机会,并减少了使用值转换器的麻烦(您不必记住或查找所需值转换器的名称)。 如果您感到好奇,我将在下面粘贴代码。这种实现的一个重要特点MatchToVisibility是,它检查是否绑定的值是一个enum,如果是,它检查,以确保Value1,Value2等也都是相同类型的枚举。这样可以在设计时和运行时检查是否有任何枚举值输入错误。为了将其改进为编译时检查,您可以改用以下代码(我手动输入了此代码,因此,如果我有任何错误,请原谅我): Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue={x:Type {win:Visibility.Visible}}, …
20 silverlight  wpf  mvvm  xaml 

1
编写框架时的依赖注入/ IoC容器实践
我在许多项目中都为.Net使用了各种IoC容器(Castle.Windsor,Autofac,MEF等)。我发现它们往往经常被滥用,并鼓励许多不良行为。 是否有用于IoC容器的既定实践,特别是在提供平台/框架时?作为框架编写者,我的目标是使代码尽可能简单和易于使用。我宁愿写一行代码来构造一个对象,而不是十行甚至两行。 例如,我注意到了一些代码气味,并且对以下内容没有好的建议: 构造函数的大量参数(> 5)。创建服务往往很复杂;尽管所有组件很少是可选的(除了可能在测试中),所有依赖项都是通过构造函数注入的。 缺乏私人和内部阶级;这可能是使用C#和Silverlight的特定限制,但是我对如何解决它感兴趣。如果所有的类都是公共的,很难说框架接口是什么。它使我可以访问我可能不应该接触的私人部件。 将对象生命周期耦合到IoC容器。手动构造创建对象所需的依赖项通常很困难。对象生命周期通常由IoC框架管理。我见过大多数班级都注册为Singletons的项目。您缺乏明确的控制,还被迫管理内部(与上述要点有关,所有类都是公共的,因此您必须注入它们)。 例如,.Net框架具有许多静态方法。例如DateTime.UtcNow。很多次,我都将这种包装和注入作为构造参数。 依赖于具体的实现使我的代码难以测试。注入依赖关系会使我的代码难以使用-特别是在类具有许多参数的情况下。 如何提供可测试的界面以及易于使用的界面?最佳做法是什么?

5
Windows 8对.NET的未来意味着什么?[关闭]
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 8年前关闭。 微软展示了Windows 8的演示,其中包括一个允许开发人员使用HTML5和JavaScript的新平台。 这个新平台是Windows 8开发的主要方式吗?微软是否正在逐步淘汰.NET平台以支持HTML 5堆栈?Windows 8对.NET开发人员意味着什么?

9
Silverlight是仅用于糖果吗?还是在商业中有用?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 既然Silverlight可以使令人叹为观止的网站变得非常美丽,那么是否有任何理由使用它来制作具有严重商业目的的实用Web应用程序?我想将其用于学习新任务,即构建一个基于Web的应用程序,以跟踪组织中使用的数据接口,但是我不确定如何证明它的合理性。 ,甚至对我自己。 有什么想法吗?如果我不能证明它的合理性,那么我将不得不使用我已经使用(似乎)已经有一百次的旧的,简单的ASP.NET方法来构建应用程序。

3
我需要帮助来决定Silverlight / Silverlight浏览器外/ wpf之间
我正处于重新编写项目的初始计划阶段,并且要在silverlight / silverlight oob / wpf之间进行选择。TL; DR结尾。 这是一个处理潜在客户/客户/约会日历的LOB应用程序。不太复杂。我正在其他地方独立研究这些选项,但我想四处询问。一些粗略的初始要求/可预见的问题是: 我必须能够使用命令行参数(sip电话)在系统上调用exe。 使SL成为问题 用户群是分布式的,我想尽可能地限制通过网络的流量,并避免一些讨厌的并发问题 我可以看到这是使用WPF的问题 软件部署/更新必须非常简单。一些用户是非技术性的(请参阅:70岁,第一次使用计算机) 现在,我们要替换的ClickOnce应用程序并不是一个大问题,而且我可以控制使用它的计算机。但是,对于用户来说,甚至不必单击clickonce“安装”按钮就更简单了。我不知道Silverlight OOB是如何处理的。 该公司计划在12个月内进行一次艰难的扩展,因此硬件部署应该快速/轻松。这个想法是在新的位置建立互联网连接,插入一些计算机,并且不需要专门的IT人员或服务器即可工作。 使SL更具吸引力 与其他服务(财务软件,asterix服务器)的集成不是近期目标,但成为系统的一部分则是最终目标。如果将单个服务设置为与那些辅助服务集成,而不必通过有线传输所有数据,则此操作将变得更加简单/高效。 使SL更具吸引力 进行多个“版本”转换是不可能的。我不知道维护Silverlight + Silverlight oob版本是什么感觉(如果有任何问题) 可能使WPF成为更好的选择。 TL; DR:从我的角度出发,silverlight应用程序最适合90%的用户,而其他10%的用户则无法使用它,因为他们需要运行exe。Silverlight OOB可能是一个快乐的中间地带,但是我目前不知道它的执行模型是什么样的(是否还有服务器端代码的概念?如果是这样,那可能是理想的选择),但我不知道了解部署/更新的工作原理。
10 wpf  silverlight 

3
XAML标记的推荐控件命名约定是什么?
在使用WPF或Silverlight时,应该如何使用控件命名约定?您是否在XAML标记中命名控件?我在Codeplex上看到了带有控件名称(例如“ selectButton”或“ btnSelect”)的项目示例。你会推荐什么?
10 wpf  silverlight 

1
如何将Silverlight应用程序移动到HTML5 [关闭]
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 7年前关闭。 我一直在使用Silverlight 5应用程序一段时间。我喜欢这项技术,并为获得Silverligt开发认证而着迷。 但是,Html5在这一点上获得了动力,这是对新应用程序的新思考。现在,我正在考虑是用Sl还是html5开发。我已经阅读了数千篇有关该主题的文章,并且不清楚是否有任何方法可以将应用程序迁移到HTML5 SL,知道是否有任何工具可以帮助该过程?

3
为什么我们有这么多种.NET?这是好事吗?[关闭]
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 8年前关闭。 .NET Framework有许多“特色” : 满(“正常”) 客户资料子集 Web浏览器中的Silverlight Windows Phone上的“ Silverlight” 紧凑的框架 WinRT 当在新平台上需要C#代码时,Microsot似乎更喜欢采用完整的CLR并将其剥离为一个小的子集,从而创建新的程序集并移动类型,而不是仅使用现有的程序集(例如BCL中的程序集) 。例如,Silverlight对于WPF具有不同的类/方法(甚至包括某些具有稍微不同的签名或非常不同的实现的方法),而不仅仅是引用与List<T>WPF 相同的实现。 这是理想的体系结构还是传统的标志?BCL不应在所有平台上都只具有不同的表示/ IO库的所有平台上运行吗?还是BCL和其他库过于ated肿,将它们拆分出来会产生太多向后兼容的问题,这是可以接受的? 如果我们从一块空白的画布开始,并且不担心向后兼容性,那么当前的状况真的是处理多个平台的最佳方法吗?
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.