{顶者有分}关于设计思路的思考-逻辑控件
我们公司内部前端的开发平台原来是ASP.NET+ASP.NET AJAX，最近想做一些大的调整，想引入silverlight技术；初步的思路是封装一套“逻辑控件”给程序员使用，程序员是针对逻辑控件来编程，而最终展现的样子是底层平台决定的，可以解释成ASP.NET+ASP.NET AJAX的方式，也可以解释成纯Silverlight实现的方式。
目标:
抽象出一套UI控件，暂命名为逻辑控件，底层平台可以根据配置将逻辑控件表现为不同的展现方式（目前需要实现两种展现方式，1.asp.net平台实现；2.silverlight平台实现），程序员不需要关心控件最终的展现方式和平台，程序员只知道逻辑控件，他们只面向逻辑控件来编程。
问题：
1.征询一下大家的思路，如果有做个类似设计和实现的朋友请分享下你的思路。
2.目前需要根据一套逻辑控件实现两种展现方式，1.asp.net平台实现；2.silverlight平台实现，不知道现在是否有这样的应用或者开源的项目可参考，如果有知道的朋友请告知。
3.有其他相关的资源，请告知。
这个问题比较抽象，没看明白的朋友请留意提问。
非常感谢，高分求教，顶者有分！
作者: progra 发布时间: 2011-03-02
该回复于2011-03-02 15:53:31被版主删除
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
|
#2楼 得分：0回复于：2011-03-02 15:49:26
|
作者: jpcai2012 发布时间: 2011-03-02
作者: liuqian4243 发布时间: 2011-03-02
该回复于2011-03-02 16:47:37被版主删除
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
|
#5楼 得分：0回复于：2011-03-02 16:26:40
|
作者: wang136206441 发布时间: 2011-03-02
分
作者: luoweihua7 发布时间: 2011-03-02
作者: wxr0323 发布时间: 2011-03-02
该贴讨论的问题就是图中黑框部分的实现
作者: li_1042237864 发布时间: 2011-03-02
该回复于2011-03-03 10:19:57被版主删除
- 对我有用[0]
- 丢个板砖[0]
- 引用
- 举报
- 管理
- TOP
|
#10楼 得分：0回复于：2011-03-03 09:00:52
|
作者: progra 发布时间: 2011-03-02
飘过
作者: progra 发布时间: 2011-03-02
该贴讨论的问题就是图中黑框部分的实现
也就是 蓝色的5、6步骤和红色的2、3步骤
作者: exiori 发布时间: 2011-03-03
作者: nishierzhizhu 发布时间: 2011-03-03
封装业务逻辑，剥离UI，你的“服务”应该不依赖任何UI形式...这其实是软件工程里比较基础的知识...
作者: Return_false 发布时间: 2011-03-03
谢谢你的建议
不过希望你先完全搞清楚问题再来做科普工作
这里，步骤9的业务插件，只是指纯前端功能的业务插件，比如控件A的数据改变，控件B,C要做响应。逻辑控件这种模式解决的就是这部分前端业务逻辑的重用问题，也就是不管未来用哪个平台来实现前端UI，这部分逻辑都不需要重写。程序员前后台代码都只开发一次，就可以得到多个平台下的前端UI。
作者: progra 发布时间: 2011-03-03
作者: progra 发布时间: 2011-03-03
你的图中，程序员负责编写业务代码和设计模型，仍然是那种“越是低级的工具越好用”的思路。要是想长期开发，那么一个软件公司应该有上百个自己独特的设计师熟悉的组件。把设计师跟程序员分出层次，才好搞一个长线产品开发（而不是小项目）。
作者: vrhero 发布时间: 2011-03-03
作者: progra 发布时间: 2011-03-03
非常感谢你的建议!
silverlight我刚刚接触，还没有深入的研究。
1.关于你说的“silverlight中有丰富的数据绑定、样式、行为、转换器、故事板等等，是给设计师用的。设计师提出底层工具的接口，例如要求程序员写一个通用的行为组件或者转换器代码，而对程序员完全可以隐藏其主要应用场景。”
请问：目前是否有现成的这种模式的应用，是否有开源的项目可参考？如果有请告知。
2.你说的意思我明白，我们做的是ERP通用产品，我这提到的只是前端的很小一部分开发模式的封装，我们同样会提供给实施股份和客户（可以把这两种角色理解为你说的设计师）使用的可以直接自定义设置产品功能的工具（不一定都是sl开发，历史原因决定会多平台并行存在），只是不同层次的应用，工具的功能会不一样，越靠近客户越傻瓜。我们觉得让程序员一点前端业务逻辑都不写是不现实的，所以肯定要提供最低级的靠定制源代码实现的功能，也就是这里的前端业务插件。总的来说就是，最终我们会提供多个层次的影响产品的开发或个性化设置的使用模式来最终得到想要的产品。
请问：基于我们这种模式，您是否还有什么好建议，最好是关于逻辑控件的设计思路？
作者: lizhibin11 发布时间: 2011-03-03
http://topic.csdn.net/u/20110302/14/af5dbb3d-565f-4008-af72-393d845aeb08.html
作者: sp1234 发布时间: 2011-03-03
如果是实现某一个平台的同控件不同展示，还有可能，这个asp.net是页面回发的，silverlight是直接内部调用服务器的，怎么可能有一个逻辑控件来模拟呢，这个逻辑控件是个装在哪儿的什么东西都说不清楚了，要想让asp.net和silverlight相同，那抽象的层次肯定要放大，最终就变成了多层架构的UI层。
作者: sp1234 发布时间: 2011-03-03
我觉得asp.net平台和silverlight平台机制是完全不同的吧，
如果是实现某一个平台的同控件不同展示，还有可能，这个asp.net是页面回发的，silverlight是直接内部调用服务器的，怎么可能有一个逻辑控件来模拟呢，这个逻辑控件是个装在哪儿的什么东西都说不清楚了，要想让asp.net和silverlight相同，那抽象的层次肯定要放大，最终就变成了多层架构的UI层。
你提到的问题在于步骤6：解析生成最终页面，也就是说要解释逻辑控件，生成最终平台的控件体系。这个问题理论上应该可行
作者: progra 发布时间: 2011-03-03
控件就是能模拟成 只有输入输出 的一个黑盒子，还是UI层的概念
或者说，你是想一个页面里很多sl控件？文本框是一个sl控件，按钮又是一个sl控件，那你站点的sl版本没什么意义了吧？
作者: progra 发布时间: 2011-03-03
不是这么简单吧，解析生成最终页面，生成html可以理解，sl可不是一个页面，难道你是生成一个xaml？那还有编译怎么办？
控件就是能模拟成 只有输入输出 的一个黑盒子，还是UI层的概念
或者说，你是想一个页面里很多sl控件？文本框是一个sl控件，按钮又是一个sl控件，那你站点的sl版本没什么意义了吧？
silverlight我刚接触不久，还没有深入的研究。
这里的逻辑控件，针对sl，我目前理解是应该生成XAML
已知的编译问题就是asp.net和sl平台的DLL之间不能共享，所以需要一套代码，分别编译，请问除此以外编译还有什么问题吗？
作者: hztltgg 发布时间: 2011-03-03
一套代码是指逻辑控件的接口，多平台共用一套代码，解析逻辑控件接口的代码各平台各不同。
作者: progra 发布时间: 2011-03-03
其实设计都是为了减少重复代码，你的思路不能减少重复代码，反而增加代码，因为我觉得asp.net和sl是从输入输出就开始不同了，UI和业务逻辑之间增加接口，共享业务逻辑，这样说可行的，但这两者UI是完全不同，完全没有什么可以重复利用的代码，为什么要这样设计呢？
作者: hztltgg 发布时间: 2011-03-03
作者: progra 发布时间: 2011-03-03
作者: progra 发布时间: 2011-03-03
原来你说的编译时这个意思，图没有错，第6步：解析生成最终页面，其实意思就是根据逻辑页面（由逻辑控件组成的一个虚拟页面），解释（就像浏览器解释JS脚本一样）生成最终页面，这里不存在先编译再部署的问题，因为一切都是动态创建的。
红色箭头部分说明的是事件流的问题，事件是靠IReceipt接口来解决的，逻辑页面把逻辑控件的所有可用的事件都映射给IReceipt接口，程序员通过实现IReceipt接口，来插入自己的业务逻辑。这个图里有一个地方没画全，就是运行时，IReceipt接口跟 运行时表单模型 直接应该有双向的红箭头，因为开发需要访问当前的表单模型，就是可以通过读写表单模型来改变逻辑页面->进而改变最终页面。
作者: hztltgg 发布时间: 2011-03-03
作者: hztltgg 发布时间: 2011-03-03
我能想到滴是要么工厂，要么生成器模式，要么文本dsl，要么条件编译
界面是界面，逻辑是逻辑
并不存在啥逻辑控件这么一说，变的只是界面不是逻辑，所以没啥逻辑控件的概念。
顶多就是在不同编译条件下去生成不同的界面
作者: nandy249407850 发布时间: 2011-03-03
恩，叫虚拟控件可能更贴切。
作者: progra 发布时间: 2011-03-03
作者: qiudong_5210 发布时间: 2011-03-03
但是看了楼主那幅图以后,
我认为:你们已经确定了生产方式,只不过对其中的某个工序的方案想征询思路,
可是,这个问题你很难让我抛开整个生产方式单独的谈论我们是怎样实现的,
对于我们而言,设计师和程序员是分工明确的,
设计师编撰业务逻辑,可是他们并不接触代码,而是提交文档,
而只有少量的代码需要程序员编写,
比如,需要动态创建一个UI容器,程序员实现了Createview_div_1_1()这个接口,
asp.net下开发写一遍,加个div;winform中写一遍,加个flowpanel,
而在编程的时候,程序员所调用的方法又是层层隔离的,基本上都是企业库事先准备好的资源;
这个接口会被用在无数的地方,程序员只关心它能否通过测试,至于什么数据和业务则不必关心
作者: wanghui0380 发布时间: 2011-03-03
树就是树，没啥逻辑不逻辑的，如果说逻辑他就是树的逻辑
至于界面，可以是treeview，也可以嵌套gridview，也可以是dropdownlist，也可以是menu，更可以是级联下拉列表
所以我认为你这个并不是撒逻辑控件，从根本上说你的要求实际是一个DSl或者元编程的东西
dsl的解释 DSL：domain specific language 领域专用语言
元编程的解释：http://zh.wikipedia.org/zh/%E5%85%83%E7%BC%96%E7%A8%8B
作者: progra 发布时间: 2011-03-03
作者: Airch 发布时间: 2011-03-03
实际这个就好比俺们经常使用的树
树就是树，没啥逻辑不逻辑的，如果说逻辑他就是树的逻辑
至于界面，可以是treeview，也可以嵌套gridview，也可以是dropdownlist，也可以是menu，更可以是级联下拉列表
所以我认为你这个并不是撒逻辑控件，从根本上说你的要求实际是一个DSl或者元编程的东西
dsl的解释 DSL：domain specific langua……
对，有道理
作者: microtry 发布时间: 2011-03-03
至于界面，可以是treeview，也可以嵌套gridview，也可以是dropdownlist，也可以是menu，更可以是级联下拉列表
-----------------------------------------------------------------
从我上面一个纯粹的对象语言程序员，很自然的感觉实际就是工厂 或生成器
不过如果是一个从事dsl方面程序员的来说，他可能会说这是dsl，元编程，条件编译，产生式编程
作者: wanghui0380 发布时间: 2011-03-03
要知道，UI首先就局限于“平台”...WPF很美，但是没有人能统一OS市场和浏览器市场，微软都不能...既然平台不可能统一，为什么要把精力浪费在那些不需要浪费的地方？
简单地剥离UI就足够了...UI设计师并不在乎为不同的平台多做一次设计，相反这些事情本不是程序员应该去操心的...WCF -> WPF/Silverlight的策略很聪明，对了还没忘了服务传统的HTML或者WinForm或者Win32 SDK...
程序员只要做好为不同平台的UI提供一致的服务，其实多一个UI多不了多少工作...
作者: hztltgg 发布时间: 2011-03-03
我们考虑的UI应该是远比你所指的UI复杂。
作者: progra 发布时间: 2011-03-03
作者: wanghui0380 发布时间: 2011-03-03
逻辑控件本身不会关心你所说的“左移一点”这种问题，控件的布局信息（包括控件的外观定义）都是在模型设计器里完成，也就是蓝色第2步，如果未来布局有改动，只改模型，逻辑控件本身是通用的接口，是稳定的。
可能会变的就是解析逻辑控件生成最终页面的实现细节可能会因为平台的更新而更新，这应该是正常的吧
作者: vrhero 发布时间: 2011-03-03
to vrhero:
我们考虑的UI应该是远比你所指的UI复杂。
那只能说明你们剥离的不够...
我不信你们的UI比Windows复杂，而Windows自从十多年前NT以来都是走这条路，到Windows 2000以后更是典型...我更不信你们的UI比X Window复杂，而X Window的概念有将近二十年了...
作者: progra 发布时间: 2011-03-03