Sencha建筑师的现实世界项目结构 [英] Real world project structure with Sencha Architect

问题描述

我是Sencha ExtJS和Architect MVC的新手，但我一般都知道MVC和其他一些JQuery库。

我想在建立一个真实世界的系统时问，在Architect 2中布置Sencha应用程序结构的正确方法是什么？

例如，我们在应用程序中有以下部门，它们具有不同的功能：

会计，控制，质量保证，客户服务，人力资源，物流，采购，销售，记录管理...

方法1：将它们写在不同的Sencha Architect项目中。用主页面+主区域+页眉/页脚+边栏页面进行缝合。 （在我们的例子中使用MVC.NET）

---优点：

• 多个程序员可以在敏捷的
  环境中处理不同的子项目。




• 每个项目更小，更容易升级或更换。

---缺点：

• 我们有不同的Sencha Architect项目，例如主要区域，侧栏，页眉，页脚。他们如何相互合作？我们现在只使用JQuery来传递它们之间的信息，但是它感觉很奇怪。

方法2：将它们全部写在一个大型的Sencha Architect项目中。所以，它在一个单一的app.html页面中的所有内容。

---优点：

• 现在，项目可以相互协作。




• 一个真正的单页面应用程序All-in-One app.html看起来不错。







---缺点：







• 如果多个程序员在一个Sencha建筑师项目上工作。




• 这是一个复杂的应用程序。虽然它分为简单的应用程序，商店，M，V，C类别，但我们可以在较大的项目中的组件名称崩溃。




• 加载速度可能是一个问题？我只是在这里猜测，因为我们不知道Sencha Architect MVC设计是否将相关的窗口和构件一部分或全部加载在一起。







问题是，如果我们采取第一种方式，我们如何在不同的项目之间进行通信？如果我们采取第二种方法，Sencha Architech 2是否旨在以这种方式构建现实世界的项目？在一个大项目中堆叠所有东西？

解决方案

首先我会说你以这样正确的方式思考这个问题。您的利弊现在出现。





第二个完全公开我是Sencha建筑师团队的工程师。





我的建议是将单独的项目与门户/仪表板应用程序相互联系更紧密，也可能连接在一起。胶水应用程序可以写成任何东西，包括建筑师中的Ext JS。





我说的这个原因只是我不喜欢把我所有的鸡蛋放在一个篮子里如果您已经构建了单页面应用程序，那么您会知道，当他们工作时，他们真的很哼但是当一个未捕获的JavaScript异常发生时，它可以强制该用户必须完全刷新以恢复到一个幸福的状态。当然，如果你是完美的，那永远不会发生：p谁是完美的？





我建立了一个实际上是一个非常大的单页应用程序的建筑师。作为一个团队，我们都尽力使每个系统能够尽可能少地依赖任何其他系统。我们使用事件，如pub / sub，适配器和插件模式等等。





这些系统非常分散在独立的命名空间和目录中，像所有软件一样开发人员划分。建筑师今天不完全支持这个想法。然而，约定你可以接近。例如HRController，HRNewEmployeeForm，HREmployeeGrid





然而，将HR作为单独的应用程序提供给HR.EmployeeController HR.NewEmployeeForm，假设你的应用程序名称是HR。每个应用程序是一个单独的项目，也允许开发团队在如何部署中更加敏捷！主要胜利





其他用户采用了这种方法，一个这样的用户使用托管iframe方法将所有项目整合在一起
http://www.sencha.com/forum/showthread.php?243179





Asp.Net MVC是另一个很好的方法，可能会为您提供一些功能，如用户auth等...





希望这有助于！ >


I am new to Sencha ExtJS and Architect MVC, but I know MVC and some other JQuery libraries in general.

I want to ask when building a real-world system, what is the proper approach to layout an Sencha app structure in Architect 2?

For example, we have the following departments in our app, they have distinct functionalities:

Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...

Approach 1: Write them in different Sencha Architect projects. Stitch up with master layout page + main area + header/footer + side bar pages. (using MVC.NET in our case)

--- Pros:

• Multiple programmers can work on different sub-projects in an agile environment.

• Each project is smaller and easier to be upgraded or replaced.

--- Cons:

• We have different Sencha Architect projects for, e.g. main areas, side bar, header, footer. How do they collaborate with each other? We now only use JQuery to pass information between them, but it feels kind of hacky.

Approach 2: Write them all in one big Sencha Architect project. So, it sarts up in a single app.html page with everything in it.

--- Pros:

• Now every component in the project can collaborate with each other.

• A true Single-Page-App All-in-One app.html looks nice.

--- Cons:

• Having hard time if multiple programmers are working on one Sencha Architect project.

• It is one big complicated piece of app. Although it is seperated into simple App, Store, M, V, C categories, but we can have name crash on components in a larger project.

• Loading speed may be an issue? I am just guessing here because we don't know if Sencha Architect MVC design loads relevant windows and compoents part by part or everything together.

Question is, if we take 1st approach how do we make communications between different projects? If we take 2nd approach, is Sencha Architech 2 designed to build real-world projects that way? stacking everything in one big project?

解决方案

First I'll say that your thinking about this problem in all the right ways. Your pros and cons are spot on.

Second for full disclosure I'm an engineer on the Sencha Architect team.

My suggestion is to have separate projects that are more loosely coupled and perhaps connected by a portal/dashboard application. The glue app can be written in anything including Ext JS in Architect.

The reason I say this is simply that I don't like putting all my eggs in one basket and if you've built single page apps you'll know that when they're working they really hum. But when an uncaught javascript exception occurs it can force that user to have to do a full refresh to get back to a happy state. Of course if you're perfect this will never happen :p Who's perfect?

I build Architect which is in fact a very large single page application. As a team we all do our best to keep each system able to work with as little dependency on any other system(s) as possible. We use things like eventing, pub/sub, adapter and plugin patterns, etc...

These systems are very much broken into separate namespaces and directories which like all software helps developers compartmentalize. Architect doesn't fully support this idea today. However with convention you can get close. e.g. HRController, HRNewEmployeeForm, HREmployeeGrid

Having HR as a separate app however, affords you HR.EmployeeController, HR.NewEmployeeForm assuming your app name is HR. Each app being a separate project also allows for the dev team to be more agile in how it deploys!! Major win.

Other users have taken this approach and one such user graphs all his projects together using a managed iframe approach http://www.sencha.com/forum/showthread.php?243179

Asp.Net MVC is another good approach and might afford you some features like user auth etc...

Hopefully this helps!

这篇关于Sencha建筑师的现实世界项目结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！