微风路线图？ [英] Breeze roadmap?

问题描述

我很想与AngularJS一起使用微风。但是我的经理关注的是产品的成熟度以及它是标题。

I would love to use Breeze in conjunction with AngularJS. However my manager is concerned about the maturity of the product and where it is heading.

是否有任何文件在那里，我可以通过我的经理给他一些保证，微风仍然会在今后的一段时间。怎么样的风险。现在有多少人已经开始使用微风＆LT;> AngularJS以及是否有风险。如果没有更多的微风那么有什么选择，如果存在的话。

Is there any documentation out there that I could pass to my manager to give him some assurance that Breeze will still be around in the future. How about the risks. How many people have now started to use Breeze <> AngularJS and are there risks. What if there is no more Breeze then what's the alternative if there is one.

推荐答案

我可以AP preciate经理的关注。我们都在努力使技术完善的赌注。这是不容易的。你开始认为供应商的大小是一个很好的指导的那一刻......他们放弃一个重大技术（微软的Silverlight和的谷歌阅读器浮现在脑海中，但例子不胜枚举）。有没有保证。

I can appreciate your manager's concerns. We are all trying to make sound bets on technology. It isn't easy. The moment you start to think that the size of the vendor is a good guide ... they abandon a major technology (Microsoft's Silverlight and Google Reader come to mind but the examples are too numerous to mention). There are no guarantees.

我们都知道些什么？

• IdeaBlade（微风的制造商）已经在该数据管理业务的自2002年（我的创始人之一，所以我知道）。这并不能证明我们会在这里的明天。它证明​​了我们的后劲，知道如何经营企业。

• IdeaBlade (makers of Breeze) have been in this data management business since 2002 (I'm a founder so I know). That doesn't prove we'll be here tomorrow. It does prove we have staying power and know how to run a business.

微风超过正在酝酿中的一年，大约6个月前看到了它的第一个版本。重要的是，设计和实施是10年以上建筑物的水果和销售的商业产品（DevForce），以解决同一组的挑战。 这讲到产品的成熟度。我们现实世界的客户不断的pressure下吸取了很多教训。目前我们已经取得了和你还没有看到失误中恢复过来一个极好的机会。

Breeze is over a year in the making and saw its first release about 6 months ago. As important, the design and implementation are the fruit of more than 10 years building and selling a commercial product (DevForce) to address the same set of challenges. This speaks to the maturity of the product. We've learned many lessons under the constant pressure of real world customers. There is an excellent chance we've made and recovered from mistakes you haven't seen yet.

它讲的承诺时，以营利为目的的公司我们这样规模的盆满钵满其大部分最好的工程和产品营销资源投入微风。这是一个巨大的赌注，对我们巨大的投资。我们不能把它走开掉以轻心。您的经理会知道。

It speaks to commitment when a for-profit company of our size pours most of its best engineering and product marketing resources into Breeze. That's a huge bet and huge investment for us. We can't walk away from it lightly. Your manager will know that.

微风MIT许可和开源。我们不能改变这一点，不想。原则上，我们可以分拆商业版，放弃开源分公司的进一步发展。但是，（一），将有商业意义，它不会在predominantly免费的JavaScript库和（b）任何人都可以派生当前code和维护的时间。

Breeze is MIT licensed and open source. We can't change that and don't want to. In principle, we could spin off a commercial release and abandon further development of the open source branch. But (a) that would have to make commercial sense which it doesn't at a time of predominantly free JavaScript libraries and (b) anyone can fork the current code and maintain it.

微风在开放开发的。你看，我们正在做的事情，我们正在做的。

Breeze is developed in the open. You see what we're doing as we're doing it.

微风文档更广泛的比你会发现在大多数的付费产品。这是遥遥领先的什么，你会在大多数JavaScript库......包括你提到了一个发现。请问是怎么回事？我们有长期的经验建立一个商业产品...足够长的时间要明白，位是一个技术产品只是其中的一部分。你决定。

The Breeze documentation is more extensive than you'll find in most paid products. It's way ahead of what you'll find in most JavaScript libraries ... including one you mentioned. Does that matter? We've had long experience building a commercial product ... long enough to understand that the "bits" are only one part of a technology product. You decide.

微软虽然不够好，微风中以特色在他们的单页应用程序的网页并与IdeaBlade重要的是使用Visual Studio的工作基于微风应用模板的开发工作。清风是不是微软的产品。但它足以越过微软的门槛，这样present它舒适。才是最重要的东西。

Microsoft though well enough of Breeze to feature it on their Single Page Application web page and to work with IdeaBlade on development of Breeze-based application templates that work with Visual Studio. Breeze is not a Microsoft product. But it has crossed a threshold sufficient for Microsoft to present it comfortably in this way. That counts for something.

我们要发布我们的路线图。它的部分由您的建议通过用户音色以及堆栈溢出问题的驱动。角支撑在这些论坛上很受欢迎。它也是由我们的市场机遇读书......在这里，再次出现折角作为一个聪明的战略选择驱动。

We should publish our roadmap. It's partially driven by your suggestions through User Voice and Stack Overflow questions. Angular support was very popular in these forums. It's also driven by our reading of market opportunity ... where, once again, Angular appeared as a smart strategic choice.

我们已经与角产品团队有良好的关系，工作就如何推动的单页应用程序的开发...在一起。这种关系的一些成果：在<一个href=\"http://www.asp.net/single-page-application/overview/templates/breezeangular-template\">Breeze/Angular模板和的演讲给了我在谷歌山对角和微风查看校园。

We have an excellent relationship with the Angular product team, working on ways to advance the development of Single Page Applications ... together. Some fruits of that relationship: the Breeze/Angular Template and a talk I gave at the Google Mt. View Campus on Angular and Breeze.

• 把我在你的位置，我想知道我的选择也有同感。 Ember.Data是另一个标杆。不作为角据我所知工作。但它确实告诉你很多关于复杂的数据管理，它需要充分满足他们什么的挑战。

• Put me in your spot and I want to know what my alternatives are too. Ember.Data is another benchmark. Doesn't work with Angular as far as I know. But it does tell you a lot about the challenges of complex data management and what it takes to address them adequately.

构建它自己始终是一种可能性。如果你想知道这是什么像环顾四周。或者用你的头，你的经验。你有多少次能够做的更好编写自己的框架，不是专门给它十年的球队吗？也许你可以。所有你所要做的就是说服老板。

"Build it myself" is always a possibility. Look around if you want to know what that's like. Or use your head and your experience. How often have you been able to do better writing your own framework than a team dedicated to it for ten years? Maybe you can. All you have to do is convince the boss.

让我们假设你可以。仅仅因为你的可以的并不意味着你的应的。你可以写你自己的角了。基础设施是发展的最富有成效地利用你的才华？还是应该重定向你的时间和精力去应用开发与顾客感知价值？

Let's suppose you can. Just because you can doesn't mean you should. You could write your own "Angular" too. Is infrastructure development the most productive use of your talent? Or should you redirect your time and energy to the application development with perceived customer value?

也许是最谨慎的事情是封装服务层内部的微风东西与拥有您希望您的应用程序组件交谈的抽象的API。如果出现问题，你已经隔离了问题你的服务层。我们所有的样品采取这种方法：找模块调用的DataContext和DataService的。

Perhaps the most prudent thing to do is encapsulate the Breeze stuff inside a service layer with an API that has the abstraction you'd want your application components to talk to. If something goes wrong, you've isolated the problem to your service layer. All of our samples take this approach: look for modules called "datacontext" and "dataservice".

目前我们的角度支持不延伸到缺乏的getter / setter属性的ECMAScript 5支持的浏览器...为FastReload观察。我们没有计划要解决这个问题。我们的研究告诉我们，大多数人建单页应用程序（水疗）的目标，其中EC5浏览器是一个给定的移动场景。我严重怀疑，这样的JavaScript为中心的应用程序将在旧的浏览器充分履行职责。但是，你应该与你的经理讨论到底为什么你要沿着这条道路和你是谁试图达成。如果你需要对旧的浏览器上运行，我不会赌微风帮你一个角度应用程序。你可以考虑切换到我们的热毛巾/基因剔除/微风栈上做旧的浏览器工作;看见约翰爸爸的单页应用程序的Jumpstart 的课程Pluralsight。

At the moment our Angular support does not extend to browsers that lack ECMAScript 5 support for getter/setter properties ... as FastReload observes. We do not have plans to address that. Our research tells us that most people building Single Page Apps (SPAs) are targeting mobility scenarios in which EC5 browsers are a given. I seriously doubt that such JavaScript-centric apps will perform adequately on older browsers. But you should discuss with your manager exactly why you are going down this road and who you are trying to reach. If you need to run on older browsers, I wouldn't bet on Breeze to help you with an Angular app. You could consider switching to our Hot Towel/Knockout/Breeze stack which does work on older browsers; see John Papa's "Single Page Application Jumpstart" course on Pluralsight.

角依赖于脏检查的变化检测和微风内部依赖于事件。这些不同的方法;他们也不会太大。例如，角钩身变为DOM事件和XHR回调。该角团队了解我们在做什么，他们不认为我们是不相容的两种。你必须要注意的规则（例如，调用$范围。$在适当的时候适用）。这不是新闻角的开发者。

Angular relies on dirty checking for change detection and Breeze relies on events internally. These are different approaches; they are not incompatible. For example, Angular hooks itself into DOM events and XHR callbacks. The Angular team understands what we're doing and they don't think we're incompatible either. You do have to pay attention to the rules (e.g., calling $scope.$apply at the appropriate times). This is not news to Angular developers.

你所需要的微风功能？取决于你在做什么。这里有几件事情微风不，你不会在角发现：客户端的查询语言，对象图导航，跟踪变化的（不一样的变化检测），模型验证，客户端缓存，临时密钥生成/分辨率，捆绑/交易扑救。这是没有棱角的批评。这意味着我们有重点的不同和互补的领域。应用程序逻辑和presentation清风的同时集中对涉及持久性数据模型事项角精矿。

Do you need the Breeze features? Depends on what you're doing. Here are a few things Breeze does that you won't find in Angular: client-side query language, object graph navigation, change-tracking (not same as change detection), model validation, client caching, temporary key generation/resolution, and bundled/transactional saves. This isn't a criticism of Angular. It means we have different and complementary areas of focus. Angular concentrates on application logic and presentation while Breeze concentrates on matters relating to a persistent data model.

这篇关于微风路线图？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！