从长远来看，RIA 框架的有效性如何？
就 Flex/RIA 框架而言，我是个新手。主要在服务器端完成工作。当我在互联网上搜索时，人们正在使用很多不同的框架，cairngorm 来配对。所以我的问题是，当我还是婴儿时，我应该学习框架吗？还是没有框架？ （到目前为止，除了完整形式之外，那些 DI、DAO、VO 和 IoC 对我来说没有多大意义。）大约八个月后，我需要做一些非常严肃的事情。那应该有足够的时间来学习 flex 吗？提前致谢。 （也欢迎任何链接或指针——尽管我花了一整天的时间在谷歌上搜索并打出“hello worlds”......）。如何成为RIA FLEX高手？
i am pretty newbie in terms of flex/RIA frameworks. mostly done work on server side. as i search on internet , people are using a lot different framework, cairngorm to mate. so my question is , as i am baby stepping through flex, should i go for learning framework ? or without framework ? ( as of now , those DI,DAO,VO and IoC doesnt make much sense to me apart from full form. ) . i needed to do pretty serious stuff after around eight month or so. should that be enough time for learning flex ? thanks in advance. ( also any link or pointers are welcome -- althogh i have spend whole my day googling around and making hello worlds...) . how to become master of RIA FLEX ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
在进入框架之前，请先单独学习 Flex/ActionScript。弄清楚如何编写一个真正的应用程序，并在没有框架的情况下让一切正常工作。
一旦您习惯了从头开始构建应用程序，然后开始查看框架并选择最适合您的需求/方法的框架。
这样您就有了良好的基础来构建，而不是依赖框架来为您做所有事情。
Before you jump into frameworks, learn Flex/ActionScript on its own. Figure out how to compose a real application and get everything working without the framework.
Once you're comfortable building an application from scratch, then start looking at Frameworks and pick the one that best suits your needs/methods.
That way you have a good foundation to build off of rather than relying on the Framework to do everything for you.
我不同意其他答案，并说你应该从一个框架开始。任何 Flex 框架都会附带文档基础，告诉您应该如何构建代码，并遵循用户文化，告诉您为什么应该以这种方式构建代码。自己开始不会让您接触到不同框架的设计者已经学到并融入到他们的系统中的一些经验教训。此外，由于原型往往会投入生产，因此当您决定需要从之前设计的临时应用程序架构转移到更定义的结构时，现在从框架开始将为您节省大量重写代码的时间了解弹性。
现在我正在使用一个非常轻量级的框架，它（大致）基于 Swiz，但我也喜欢 Mate。
I'm going to disagree with the other answers and say that you should start off with a framework. Any of the flex frameworks will come along with base of documentation that tells you how you should structure your code and a user culture following that tells you why you should structure your code that way. Starting off on your own won't expose you to some of the lessons that the designers of the different frameworks have learned and baked into their systems. Additionally, since prototypes tend to get pushed into production, starting with a framework now will save you a lot of time rewriting your code when you decide that you need to transfer over to a more defined structure from the ad-hoc application architecture you designed before knowing flex.
Right now I'm using a very lightweight framework that's (roughly) based on Swiz, but I also like Mate.
我会在没有任何框架的情况下开始，这样您就可以习惯创建表单、皮肤、类和事件处理。一旦你对此感到满意，那就拿起一个框架。
查看 Tour De Flex 了解一些基本 Flex 代码的精彩示例。
I would start without any frameworks so you can get use to creating forms, skin, classes and event handling. Once you are comfortable with that, then grab a framwork.
Check out Tour De Flex for some great examples of basic flex code.
我建议先学习技术（概念和语法），然后使用框架。既然你提到你已经做了很多服务器端编码，我建议在学习了 Flex 的基础知识之后（参考 http://livedocs.adobe.com/flex/3/html/help.html)，学习 cairngorm因为它遵循常规 MVC 模式的相同原则，所以您会自然而然地想到它。
I would suggest learn the technology first (concepts and syntax) and then use a framework.Since you mentioned you have done lot of serverside coding, i would suggest after learning the basics of flex (refer to http://livedocs.adobe.com/flex/3/html/help.html), learn cairngorm as it would naturally come to you, since it follows the same principles of regular MVC pattern.
根据我的经验，我在没有任何框架的情况下开始使用 Flex。在flex中，事件处理和其他功能都非常好。因此，您可以构建不需要任何框架的小型应用程序。根据我的经验，如果您要使用框架完成所有操作，那么成本将非常昂贵。对于 cairngorm，您必须创建许多类。但如果你想构建一个复杂的应用程序，最好选择框架。这将帮助您构建具有通用外观的应用程序。更重要的是，这将帮助您稍后调试应用程序。
一切顺利...
享受编码的乐趣；-)
In my experience I started flex with out any framework. In flex the event handling and other functionalities are very much good. So you can build small applications that not require any frameworks.In my experience if you are going to do everything using framework it will be much expensive. In the case of cairngorm you have to create a number of classes. But if you want to build a complex application it is better to go for frameworks. This will help you to build the application with a common look. And more over this will help you to debug the application later on.
All the best...
Enjoy coding ;-)
从没有开始 - 原因是您甚至可能不需要您正在从事的项目的框架。即使在 Java 世界中，许多应用程序都非常小和简单，以至于您不必要地通过添加架构“以防万一”或仅仅因为这是假定的最佳实践而使其变得更加复杂。
当您选择一个框架时，请非常清楚它所产生的额外工作量（大多数确实需要一些额外的时间来使用）并将其纳入您的决策过程中。小型项目可能不需要像 Cairngorm 或 PureMVC 这样的重量级框架。
当您第一次查看框架时，请尝试一些可以让您保持对设计的控制的东西。 （许多所谓的框架实际上是微架构，Cairngorm 正确地指出了这一点，这意味着它们决定了架构的一部分。）很多人喜欢它，但我避免使用 Mate，因为它感觉配置太多。 Swiz 是一个不错的“轻量级”选择，因为它为您提供依赖注入和其他一些有用的小技巧——但它占用空间很小，并且不会真正对您施加任何任何。
永远不要听别人告诉您必须做 X，因为这是“最佳实践”，而没有具体解释为什么这是最佳实践。即使这是一个好的做法，也不是所有“好的”做法都适用于所有情况。
Start without - the reason being that you may not even have a need for a framework for the projects you're working on. Even in the Java world, a lot of applications are just so small and simple that you're needlessly making it more complex by adding in architecture "just in case" or simply because it's a supposed best practice.
When you do select a framework, be very aware of the level of extra work it is creating (and most do take some extra time to use) and factor that into your decision making process. A small project probably doesn't need a heavyweight framework like Cairngorm or PureMVC.
When you do look at a framework for the first time, try something that lets you stay in control of the design. (Many so-called frameworks are actually micro-architectures, which Cairngorm correctly points out, which means they dictate parts of your architecture.) A lot of people like it, but I avoid Mate because it feels like too much configuration. Swiz is a nice "lightweight" choice to start with since it gives you dependency injection, and some other little useful tricks--yet it has a tiny footprint and doesn't really force anything on you.
Never listen to someone telling you that you have to do X because it's a "best practice" without having a concrete explanation for why it's a best practice. Even if it is a good practice, not all "good" practices apply to all situations.