博客园_似水流年

智诚B2C1.31正式发

2012-01-16T02:41:00Z

智诚B2C1.31正式发

智诚b2c1.31版本于2012年1月10日正式发布。欢迎各位的关注和更新。

更新功能如下：

1. 优化前台模板机制，加入小部件widget功能，可直接添加管理widget，前台界面可直接可视化添加widget，拖动设置顺序.
2. 前台可直接添加自定义界面，选择布局，进行内容自定义.
3. 站点栏目管理
4. 广告位管理功能，后台维护广告内容，前台通过widget灵活展现广告
5. 可配置前台是否显示商品的市场价
6. 后台添加商品库存查询功能
7. 后台工具箱添加自定义页面内容维护功能，包括暂停营业控制，及显示内容编辑，无法找到页面、执行出错页面、搜索为空页面的内容维护.
8. 后台工具箱添加数据库检验功能，可直接检查数据库结构是否正常
9. 后台工具箱添加数据体验数据清除功能，可直接在线清除测试数据
10. 后台工具箱可直接通过筛选条件导出商品数据、订单数据和会员数据，导出的数据源可直接设置。
11. 在后台可控制是否开启前台商品评论
12. 后台管理员登录显示首页调整
13. 计划任务管理功能加强，可直接启用禁用任务，修改任务参数
14. 后台界面菜单调整
15. 添加外链统计、跟踪功能
16. 添加站点地图自动生成功能
17. 添加热门搜索词维护功能
18. 商品缩略图处理不变形处理，缩放大小可自定义
19. 后台添加库存预警功能, 预警临界值可设置
20.后台添加新订单提醒功能
21.商品批量编辑功能加强，可直接调整价格，库存和基本信息，调整方式更加实用
22. 将帮助中心整合到系统后台中，可直接点击链接到帮助界面，查看智诚b2c的使用帮助
23.商品套装的库存，发货处理细化
24. 信息通知机制整合，每个通知点可灵活选择短信、邮件、站内信息，并可单独维护内容模板，短信和邮件发送全部采用延迟发送，可直接查看发送队列，控制发送顺序
25. 后台添加余额明细查询功能
26.修复v1.2遗留全部bug

本文链接

淘宝商城涨价，商城小卖家应该怎么走？

2011-12-20T09:18:00Z

2011年10月13日，淘宝规定了新的收费标准：技术服务年费和违约保证金涨幅达5倍至15倍。经过5万反淘宝商城联盟“志士”的斗争，也仅仅只是将降价日期推迟到明年。而淘宝东家马云微博“力挺”涨价新规则，对卖家的抗议毫不退让。

现在这种局势下，做为淘宝卖家（当然不同卖家收支情况不一样），在面对淘宝收费大幅倍增的压力，想把生意或公司继续做大做强，究竟应该怎么走？这里总结了两条路：

第一条路，继续跟淘宝走，继续做商城，多交几万十几万了还是继续做你的生意，可能你以前赚现在也赚，也可能以前赚现在亏。可是，无论是对于收入利润多少的买家来说，淘宝提价的这一做法都很值得思考。

从06年马云的“免费承诺”开始，淘宝就吸引招纳各界商户入驻，不断壮大规模，马老板相继出了淘宝商城和一淘。淘宝商家共同努力让淘宝现在流量全国第一，高出京东好几倍，如今马云却痛下杀手，要10倍收费且短期内不会改变，过河拆桥，居心何在？

先压低门槛，请君入瓮，再把圈子放大，并借此开辟并建立阿里生态环境，继而开始收费提高门槛，从而建立自己真正的“质量版”新淘宝商城。

其实，马云的“免费”承诺并非是“永远”二字。但从“免费的天堂”坠落到“付费的地狱”，面对这种巨大的落差，很多商家还是很难接受的。

对于留在淘宝做的各位商家，我想提醒，马云能有第一次提价，也自然会有第二次，从一淘的事来看，给大众提供服务的基础还是得首先满足自己的事业。交的钱不如把自己单独做起来，只有真正让自己当家才是王道！

借马云的地盘发展，他有资本有实力他可以变卦，而你又能怎么样？其实你也懂，你得把自己的产品变成高额“保护费”交了，却只能继续蒙受着说不出的苦闷，只能做自己的销量梦！当然你要说你愿意，这钱你真不在乎，那我绕行。

再者的做法，就如同很多淘宝老卖家一样，跳出淘宝或仅留部分力量在淘宝，创建自己的网上商城，建立真正属于自己的商业大本营。如今很多B2C网上商城（如凡客、乐淘、名鞋库等）的出现都已经给大家说明了成功的案例，淘宝并不是不可战胜的。如果淘宝方继续肆无忌惮的涨价收费，必将失掉大部分人的信任。

做电商不是做“淘宝”，我们需要的是真正的能让所有民众方便的服务商，只要把握好这个原则去宣传自己的产品并做好自己的义务，自然会有很多人来支持你自己的网上商城。

“与其寄人篱下，不如自己招兵买马，自给自强，发展自己真正的电商实力。”智诚佳欣CEO苗志勇说道。如今独立B2C网上商城不断壮大并有新成员加入：京东刘强东自建物流体系；苏宁国美的网上商城相继出现都说明了独立B2C市场前景广阔，我们不能只看淘宝一家独大，肆无忌惮。现实的电商世界像很多人想的那样“一家强大从而难出其右”。

此外，继shopex和ecshop都更新异常缓慢之后，众多的电商“送水人”也都浮出了水面，智诚B2C新版本1.3升级完成；360shop的快捷支付等，不仅功能完善，而且性价比、潜在价值也更加优秀，相对来讲这些体系反而更加适合中小型企业的不同情况，并能长期合作和二次开发。这些都说明了淘宝商不是只有淘宝一条路可以走，按自己的创意做自己的商城，走出自己的电商路，并且走的更好，我们完全是可以做到的！

电商的世界变化太快，现在已然不是需要庞大的几千万几个亿才能做出一个有规模的B2C网上商城，它的门槛已经被降低了太多。如今很多区域型B2C、区域连锁B2C就非常受到欢迎和追捧，在当地就有了很不错的市场份额占有量。面对淘宝的做法，我们必须随即应对，把鸡蛋放在同一个篮子，让自己继续在淘宝待下去，倒不如自己做独立网店当老板，把自己的产品和公司做大做好。

机会就像这个世界一样，变化太快，如今，建立自己的独立B2C网上商城已然不是痴人说梦，如此大好时机更该果断把握，它必然是众多淘宝卖家或企业最终选择的道路。早一日起步，未来的你就能在电商界多给人一份印象。

Well，无论怎么走，都希望大家走向自己满意的成功！

本文链接

优秀电商服务公司网址整理

2011-12-13T07:32:00Z

本文整理归纳了现在市面上的一些优秀电商服务公司（也称电商“送水人”）的软件网站，包括B2B、B2C、ERP、CRM以供大家参考，希望对有电商意向的您有帮助，同时也很欢迎大家补充。

因为我自己也是做电商这一块的，所以就按我的经验来整理，希望对有电商意向的朋友起到参考作用：

1、 Ecshop开源网店官方网站解决方案：http://www.ecshop.com/program.php

2、智诚佳欣官网解决方案：http://www.zcjxsoft.com/Solution/Index.html

3、 ShopEx官方网站解决方案：http://www.shopex.cn/service/

4、 Hishop官方网站解决方案：http://www.hishop.com.cn/efx/

5、同徽公司电子商务软件B2C产品：http://www.itonghui.com/news/B2CChanPin/

6、创想产品电子商务网站：http://www.bg68.com/Product.html

7、金蝶友商网电子商务软件：http://www.youshang.com/products/

8、伟库电子商务管理软件： http://app.k.cn/

9、用友电子商务解决方案：http://www.ufida.com.cn/solutions/index.aspx

10、铭万网管理软件：http://soft.b2b.cn/

11、金算盘管理软件：http://www.eabax.com/

12、e商部落：网店管家 http://www.es86.com/

13、普渡e-ERP集成系统：www.pudusoft.com

14、Xtools： http://www.xtools.cn/

15、CRM测评：http://www.technologyevaluation.com

16、总管家：http://www.timenote.com/

17、百会CRM在线办公SAAS：http://www.baihui.com

18、行动健力CRM：http://www.runwellcrm.cn/Downloads.aspx

19、国外一款CRM：http://www.zoho.com/

20、网上管家婆：http://www.wsgjp.com.cn/Main.gspx

21、IBM ：http://www-900.ibm.com/cn/services/bcs/solutions/crm.shtml

22、进销存管理软件下载http://download.pchome.net/industry/retail/page-173-1–1.html

23、亿禧网：http://www.72ec.com/ 全程电子商务

24、Salesforce中国：http://www.salesforce.com/cn

25、Sales Logix：http://www.sagesaleslogix.com/

26、 Microsoft Dynamics：http://crm.dynamics.com/

本文链接

电商界风气云涌，坑爹马云难阻电商自立！独立商城B2C后浪劲更足！！

2011-12-10T09:28:00Z

今年的中国电商企业不仅在国内国外信誉大减，更是明争暗斗不止，这一切的中心，都围绕着曾经被大多数人称道的创业巨子——马云。

话说马云你坑了整整一年的爹！年初你用支付宝坑了雅虎的股市；继而用淘宝商城坑着淘宝的卖家，高达十倍的涨价让中小型B们大放血；还打着帮助B2C的旗号，大摇大摆的干着让所有卖家为你的一淘出血的“恶行”；不仅如此，更把阿里巴巴的员工坑掉了2000万，坑爹的马云，现在你到底是要干嘛？

自从马云进驻商派后，独立网店服务公司的两面大旗shopex和ecshop开始摇摇欲坠，从shopex4.84停止升级的，到ecshop被囚禁在商派难获自由和空间。同时也有不少疑问，连占市场份额绝大多数的独立商城系统都遭受着如此厄运，那独立商城是否还有前景可言？

答案是肯定的，有！必须有！

“没有自己的商城而过度依赖像淘宝这样免费的第三方平台，等这些第三方平台做大做强之时也就成了众多小卖家的灭亡之日，所以拥有一个属于自己的独立B2C商城才是最佳选择”智诚佳欣CEO苗志勇先生表示。

在马云的坑爹之举之后，太多淘宝的B们已经开始寻找出路，中小型企业与其把自己的利润都出血“奉献”给一淘，给阿里巴巴，还不如创建自己真正的电子商务大本营，打造自己更大招牌和更加独立的门户。

跟着马云是坑自己！不如我们自己独立自己干！

让自己的产品红遍有着几千万甚至上亿网民的互联网是每个现代企业家的梦想，让自己的招牌占有网络的一席之地毫无疑问是正确的思路。

很多淘宝上的老卖家，都已经转型而进入了独立商城领域，开发自己的B2C网上商城，抢夺市场先机，按自己的想法来装饰属于自己的店面。淘宝的这套C2C和淘宝商城的这套B2C就是无底洞，让各位B们交着各种费用，还得按他们的规则办事，更要为马云你时不时的提价想法而担心受怕，这实际上将卖家自己的命运掌握在了别人手中。

如今，各种网上商城已然出现，B2C网上商城的技术发展已经比较成熟，市面上已经存在的各种B2C网上商城如shopex、Hishop、智诚佳欣B2C和ecshop在技术上已经非常接近甚至相差无几，仅仅只是品牌或名气有所不同而已。

独立网店的强大功能后台，可以帮助您灵活实现全国快递、在线支付、推广活动、会员活动、特价销售等功能，相比淘宝、易趣等C2C平台，更为专业全面。而且独立网店大都还拥有模板系统，不但美观大气，而且模板多样，网上有很多免费模板可以使用，带来更多选择。

另外还有一点，相比C2C店铺的装修费、保证金、旺铺费、推广费等费用，独立网店的成本并不算高，而且从长远利益来看实则是一项具有战略眼光的投资。

越来越多的企业建立B2C网上商城，拥有自己的销售平台，就为自己加了一份筹码。选择淘宝，不如做真正的自己。当当、卓越、海盗船这些成功的案例向我们说明了很多问题，事实证明了其实用性。做个B2C网上商城，就好比在商厦隔壁建立一个同样招牌的店面，其优势自然可见。。

Shopex和ecshop受了阻碍，但B2C网上商城的发展从未停止过！很多 “后辈”们结合了前者之所长，运用新的技术已经开发出了比较成熟的产品。不仅仅是相对更低廉的价格，他们更大的看点在于他们长期合作中的无私奉献和更快更好的售后服务机动性。像shopex、智诚b2c、hishop、v5shop、360shop这些都给众多的企业家们提供了开创自己独立B2C网上商城的途径，他们就是电商背后的“送水人”。

从投资的角度看来，把所有的鸡蛋放在一个篮子里是非常危险的，我们不能坐以待毙，早打算，早规划。投给淘宝的巨额资金还不如组建和完善自己的公司团队，招兵买马。打造一个自己的电子商务销售网站，前期充分利用小团的灵活性开展网络营销工作，相信一定会创造新的财富和事业蓝海。

走出淘宝的“牢笼”，选择一家这样的电商“送水人”与您一起成长，不失为一条企业更快更好发展的上上策。

本文链接

四大网店shopex,ecshop,智诚b2c,hishop比较

2011-12-08T08:45:00Z

经过笔者多年的使用经验和调查，针对ShopEx、ECShop、智诚b2c和hishop这四大网店系统的分析比较结果大致如下表所示：

	shopex	ecshop	智诚b2c	hishop
操作系统	Linux/FreeBSD	Linux/FreeBSD	Windows Server	Windows Server
Web服务器	Apache	Apache	IIS	IIS
数据库	MySQL	MySQL	MSSQL MySQL Oracle	MSSQL
开发语言	PHP	PHP	ASP.NET	ASP.NET
功能性	√	√	√	×
易用性	√	×	√	×
搜索引擎优化	√	×	√	√
插件模板	√	√	√	×
二次开发	×	√	√	×
在线文档	√	√	√	√

在国内的电商竞争平台中，现找出四家较为典型的电商公司做对比分析，其对应介绍分别如下：

shopex (http://www.shopex.cn)
ShopEx作为老牌的网店系统提供商，以功能全面、易用、强大见长，可以说是国内最具权威的一个网店系统，无论从什么角度来讲其都是具备了行业领导性意义的。ShopEx基于PHP+MySQL开发，采用Linux+Apache+MySQL+PHP架构，拥有较高的系统安全性和稳定性。

ECShop( www.ecshop.com )
ECShop是国内最大的开源免费的单用户商城，它采用PHP+MySQL开发，操作简单、人性化，与Discuz!论坛可以无逢整合，拥有灵活的插件机制，模板开发简单。

智诚b2c(www.zcjxsoft.com)
智诚B2C是网上商城的后起之秀，它充分吸收了其它网店的优秀功能，并加些整理。而且能够满足企业级电子商务系统的需求。

HiShop( www.hishop.com.cn )
HiShop作为老牌的网店系统，拥有较强的综合性能。系统的研发采用最新的ASP.NET 2.0技术，其开发的语言.NET和数据库MSSQL及安装环境WinNT都为微软软件产品，稳定性与安全性极强，目前拥有用户12万。HiShop后台操作非常简单，拥有代理加盟等特色功能。

针对不同公司的产品，其产品功能的侧重点自然也有所不同，经过笔者的整理，做了如下的比较和分析：

shopex经过多年的积累，产品功能强大较为完善，后台操作可以灵活设置筛选条件和显示字段，多种促销活动可以自由选择，在批量编辑方面表现尤为突出，可以对指定某一些商品进行价格、库存、分类、品牌、搜索引擎优化等多方面调整，在单据处理方面，shopx提供的业务流程较为简单，能够满足一般的个人网店或小企业网店的需求。具有订单、收款单、发货单、退货单、退款单，而且支持多个物流公司的快递单的在线设计打印功能

ecshop功能较为细致，针对某一方面的功能来说，ecshop并不逊色于shopex,我想这也是shopex收购这个强大的竞争对手的原因之一，在商品维护方面，ecshop可以不通过插件机制就能够实现商品抢购，扩展分类等功能，在批量编辑方面，ecshop中可以针对一个或多个指定分类，一个或多个指定品牌下面的所有的商品进行某些字段的维护，在单据处理方面,ecshop更为细致，可以单独的编辑某一块订单的内容，同时也支持后台新建和处理订单。只不过在商品SKU处理方面，ecshop要稍逊shopex

智诚b2c是一款建立在这些优秀产品这上的一款产品，完全吸收了这些产品的优秀的功能，在商品管理方面，象shopex一样完全支持sku，从商品维护，到订单处理，全部基于sku，能够满足多行业的需求。促销活动方面，同样可以设置灵活的多大十几种的活动规则，应有尽有，而在单据处理方面，智诚b2c完全满足不同规模的企业的需求，体现出企业b2c多年经验的积累，更加规范化的单据处理业务，再加上流程可配置性，同样可以满足小企业的需求。

hishop在功能上要比以上三个产品逊色很多，产品的架构比较老，功能也更新很缓慢，商品对于sku的支持不完善，促销活动支持较为单一，单据处理也过于简单

同时，对于四种产品的多个方面，给出了以下五个方面的分析供参考：

易用性：

shopex后台易用性不错，查询条件，显示列可自定义显示，前台模板机制灵活，可实现可视化设计,ajax技术在前后台应用广泛。
ecshop的易用性一般，后台功能细化，但过于零散。操作界面跳转太多
智诚b2c前台功能在现在的版本中一般，但后台基于RIA技术，操作确实方便很多，信息显示量很完善.
hishop貌似还是没啥优点

运行效率：

shoepx采用了key-value存储，前台性能还行，后台有些时候操作会有些慢，反应不及时.
ecshop的性能会好很多，很大程度上原因在于ecshop走项目二次开发方向。
智诚b2c的前台性能卓越，基于企业级mvc技术，前台反应很迅速，后台基于RIA技术，响应一般
hishop的后台性能还行，前台确实有些慢，是基于微软笨重的asp.net服务器控件所致，而且前台的模板机制是一个诟病。

搜索引擎优化：

shopex能够全局设置关键字规则，也可以单独设置，可以覆盖全局的规则
ecshop对这个方面支持不够，没有明显的特点
智诚b2c能够对前台界面全静态化，非常有利于搜索引擎优化，而且可以象shoepx一样，全局设置规则，局部设置可以覆盖规则
hishop虽然可以针对每个商品设置标题、描述、关键字，但是不能全局设置规则，比shoepx,智诚b2c要差很多。不太实用.

二次开发支持/开源支持：

shopex在这方面比较保守，只开发前台，业务层不容易扩展
ecshop完全开源，可以通过开源满足一些客制化需求，是开源网上商城的首选
智诚b2c 前台完全开源，而且对于业务层的扩展支持的比较好，客户可以基于现有的业务直接扩展新的业务
hishop虽然免费，但不开源。虽然源代码可以破解，但是比较复杂。

模版机制：

shoepx的模板机制较为完善，现成的免费模板和收费模板都比较多，另外在后台可以实现模板的可视化设计，开发一套新的模板的难度相对较低，但是其规范性限制了一定的灵活性.
ecshop由于完全开源，模板机制方面，如需要修改，相当于直接重写或修改前台代码。
智诚b2c的模板机制也同时实现了模板的可视化编辑，效率在设置完后台直接查看，但是现在现成的模板数量较少，不过定制开发模板的难度也比较低。
hishop的模板直接是使用了大量的服务器控件写的，开发的难度太大了，基本不太现实

针对以上几个方面的介绍，相信有电商意向的读者对于服务公司的选择有了一个基本的认识和了解，下面笔者根据经验，给出对选择网店的几个建议：

shoex针对于个人或小型企业，他的功能完善基本上不需要定制开发就能够满足您的需求，但是据说这个产品已经被商派停止开发新版本了。
ecshop适合于玩网店的个人，操作较为方便，但如果您没有这方面的人才，而还需要定制开发，您可以慎重了，毕竟这个产品已经被收购，官方支持也基本中断了。
智诚b2c虽然是一个新的产品，但是建立在这些优秀产品的基础上，综合了他们的所有的优秀功能，而且具有企业级大型b2c的开发和集成经验，如果您考虑到后续的规模，建议您选择智诚b2c
hishop适合批发站点，如果您有批发方面的需求，建议您选择hishop

最后，希望整理的这些资料和信息能对您选择最正确，性价比最好的网店有一个最好的帮助，如果有什么补充可以留言，有时间一定会整理。

本文链接

智诚佳欣：忠实的“电商伴侣”

2011-12-06T09:42:00Z

如果您有在网上关注着各种B2C独立商城，或者您希望能为自己公司的产品开设一个像京东、当当、一号店这样有自己独立网络销售体系的网络“店铺”，那您已经在寻找和关注各个电商平台系统提供商了。

“保守点讲，在中国，没有10年时间，10个亿资金投入，谁也别想做成一个像样的电子商务公司。”京东商城CEO刘强东如是说。2011年3月27日，深圳市电子商务大讲堂，台下大大小小电商和关注电商、有做电商想法的创业人都被泼了冷水。

其实老刘指的是要成为一个体系完整、服务到位、用户购物体验俱佳的电子商务公司需要具备的时间和物资上面的投入，并不是说在中国就不能有其他人做电子商务了。虽然电子商务的大环境在中国还没有成熟但是新一代的电商“送水人”已经逐渐浮出水面。这些电商服务公司为那些想涉足电子商务领域的创业者们解决了很棘手的难题—----电商平台搭建。正因为有了这些“电商伴侣”的出现，使得我们进入电商的道路稍微平缓了一些，更让我们的创业者们可以把注意力集中在业务和服务这些核心的地方。

做电子商务服务的公司在中国已经有不少，其中比较知名的有ShopEx、HiShop、V5SHop等。

当您在关注独立B2C商城，有着想给自己的企业和和产品创造一个具有完整商品展示、严谨销售体系的网上商城的时候，您现在又多了一个新的朋友—---智诚佳欣。

这是一家具有成熟技术经验和解决方案的电商服务公司，在公司开创至今的六年内，一直充当着为众多想走进电子商务领域的中小型企业“圆梦”的角色。

“电商界的行情可能瞬息万变，但技术+服务才是硬道理。想让顾客满意，我们必须要有过硬的技术和最好的服务态度。”智诚佳欣CEO苗志勇先生表示。

智诚佳欣是给中小型企业进入电子商务领域提供B2C、B2B、ERP等软件系统和服务的公司，主要是针对管理软件、电子商务整体解决方案和企业集成业务。所有解决方案均具有很强的可塑性，针对每个客户不同发展阶段不同需求进行调整，具有很强实用性和针对性。

在技术支持和专业性方面，相对于shopex和ecshop这两个老牌的电商服务公司的产品，其旗下重量级产品“智诚B2C“则是一款建立在“巨人肩膀”上的产品。它完全吸收了其他产品优秀的功能并且融入了自己多年的电商服务经验和数字价值。

“电子商务功能的开发有80%是雷同的。”李钟伟说。因此注重服务的商家才能真正笑到最后。智诚佳欣正是这样的一家视用户价值为生命的公司，它提供给客户的不仅仅只是一个完整的电商平台，更多的是让接受服务的每一位从内心深处认同他们的价值和理念。

在产品开发的过程中，智诚佳欣抱着“以客户为中心，客户的事业就是智诚的事业和与客户共同成长”的信念。当您安装了智诚B2C之后，他们的客服人员每过一段时间就会主动打电话咨询您当前的使用情况、使用过程中有哪些不足之处或是建议的地方。在这些简单的咨询过程后，他们下一个版本的产品当即就会去针对性的做调整或者补充，并且免费为客户更新到最新的产品，持续的为客户提供价值和服务。

有些大中型的企业可能有自己的IT开发团队，他们不满足于只需要一套系统，更多的是以此系统为原型，继而在上面做二次开发和扩展。对于这样的需求，智诚B2C则提供源代码并可以做技术转移和咨询服务。在过去四年中，智诚B2C二次开发的客户满意度达到了惊人98.8%。

11年初，天津市一家中型企业因为业务调整需要智诚B2C马上做出相应的调整，商场如战场，商机一纵即逝。智诚佳欣的员工们加班加点，连续苦战3天3夜，终于在客户要求的日期内完成了任务，给客户带来了成功和丰厚的利益。事后客户深情的握着智诚佳欣CEO苗志勇先生的手说：“太感谢你们了，没有你们真不知道改怎么处理！”。“急客户之所急，尽最大的努力保证好我们的服务。”苗志勇先生在员工会议上这样说道。

现在，智诚佳欣的员工仍然在为客户的想法而努力着，为更好的垂直B2C平台、区域型O2O平台而抓紧研发。公司将在不断的进步和壮大中吸收更多的营养，将客户圈的规模做大做强。同时，他也希望公司在未来能招贤纳士并和更多的大企业合作。

“做好客户的忠实‘伴侣’，就必须有一些能够长期合作的企业作为合作伙伴，在给客户持续提供价值的同时需要与企业有更多的了解，这样才能精准深入的体会到客户的真正‘疾苦’。“智诚创业者们时常会思考这些问题。

如今，在中国这个“不做电子商务将无商可务”的电商爆发年代，能出现这样一些默默为电商创业者们提供服务和价值的“伴侣”实则是一件幸事，让我们在电商创业的艰辛路上感到阵阵暖意。

本文链接

智诚佳欣-专业的电子商务提供商

2011-05-06T14:42:00Z

ZCB2C是一款专业的电子商务管理系统。系统拥有完善的商品模块、购物车模块、订单模块、支付模块、物流模块、会员模块、营销模块，报表分析模块等B2C网站必备模块，同时企业也可对本系统进行二次开发，从而大大减少企业搭建B2C网站的总体成本与潜在风险，让企业将更多精力专注于商品的经营层面而不是技术层面。

ZCB2C采用模块化的架构设计使得后期开发维护系统的成本大大降低，我们将电子商务平台看做一个大的工程，把它分成几个模块，模块内部解决模块负责的部分，再把他们组装成一个完整的电子商务平台。

基于.NET分层开发

ZCB2C的N层架构设计为系统提供了充分的可伸缩的特性，使ZCB2C扩展性能够适应各种电子商务平台的规模和应用需求。基于企业级架构能够更好的应对系统集成，分布式集群，高性能，故障恢复和信息安全。

良好的易用性

ZCB2C产品在研发的过程中充分考虑了人性化的操作，真正从用户的角度出发，细化到每一个操作，通过众多人性化而便捷的细节设计来体现系统其良好的易用性。

前台模板与后台程序实现完美分离

ZCB2C前台使用了MVC和模板引擎，让前台页面和后台程序实现了完美的分离，前端后端互不影响，可以根据不同的客户定制不同的前台界面，同时采用自主开发的模板引擎大大提高了前台解析速度，采用纯HTML模板是常规.Net控件编程速度的5-10倍。

产品介绍：http://www.zcjxsoft.com/contents/33/108.html
     成功案例：http://www.zcjxsoft.com/channels/18.html
     在线演示：http://www.zcjxsoft.com/contents/33/109.html
     购买咨询：http://www.zcjxsoft.com/contents/6/4.html

本文链接

[翻译] DSL和模型驱动开发的最佳实践(4/4)

2010-04-08T03:06:00Z

剩下的部分我不再直译了，累了，呵呵，而且里面掺杂着我的理解.

3 处理模型

解析器 vs   代码生成 (未评级)
         通常大家都会倾向于生成代码，其实解析也是一种可用的选择，在我们完成我们的元数据模型后，由解析器读取这个元模型数据，可以查询或者遍历模型，可以直接计算，进行相互处理，UI呈现.
         对解析与代码生成之间进行权衡, 代码生成的优点:
            1. 更加简单，生成的代码我们可以检查，另外生成代码采用的模板都是我们通过之前手写的代码抽象提炼出来的.
            2. 比解析的方式更容易调试
            3. 通过扩展代码的方式，更加强大，定制性强，可以根据需求灵活开发出更加强大的功能，比解析器更加有效
            4. 直接可以是任何目标语言和平台，因为生成的目标语言代码是由模板控制的，我们只需要定制不同语言的模板即可。如果目标语言支持其它平台，那这种方式自然也支持，而解析器的方式要求直接运行在目标平台上
            5. 使用生成代码的方式，使MD*模式更加彻底. 直接模型驱动业务，驱动界面
          解析的优点:
            1.修改模型不用经过重新生成/重新编译/重新测试/重新部署这些步骤,明显缩短了周期.
            2.整个系统都基于模型，甚至可以做到直接在运行的系统里修改我们的模模型，使修改立即生效. (比如一些在线saas系统).
            3.对于一些案例来说，解析器和模型会比生成代码还会省事
          解析和代码生成的方式也可以结合使用，直接生成些XML格式的模型数据，然后由3GL语言，比如java解析器来解析,驱动整个系统的运行。另外一种方法理论上也是可行的，在解析器内即时直接生成代码，提高性能.

           单独的模型检查机制
           元数据模型所表达并不一定是正确的，里面有大量的用户输入。模型约束是必须的，并且要贯穿整个模型处理，约束不仅判断是否有错误，还要有具体的错误信息能够提示给用户. 模型和约束越多，用户出现的错误也就会越多，不过这才能够保证目标系统的正确性。一定尽量多地做约束检查!
           约束检查在模型处理过程中应该尽量的早，不能够把约束放到代码生成阶段，会使模板过于复杂而且复用性差，你如果有不同的语言模板，还需要不同的检查实现。如果模型有问题，就不应该允许代码生成，否则只会带来更多的问题。
           需要在模型处理过程中的不同阶段，模型的不同部分，检查不同的约束. 比如在转换之后需要检查，在保存分区需要检查，在用户的一些输入后需要检查，在用户对模型进行一些操作后需要检查
           在模型的改进过程中，在每个级别都要进行检查，防止修改过程中的一些级联影响，另外一定要确保每个级别每个点都检查到，只是检查从上一级的正确输入是肯定不会失败的，但是用户并不是的输入是不可信的.
           对检查结果信息分不成的级别，比如错误和警告，如果发生错误，就不能够进行下一步了，警告则不是。

           不要修改生成的代码
          即使模型生成了代码，在大多数情况下，手写代码还是必须的。所以我们要把手写的代码和生成的代码结合起来，更不能够每次生成把手写的代码覆盖掉.大多数工具提供了所谓的保护区，在保护区里你可以插入你的手写的代码，来保护不被覆盖。
          这样也会有一些问题，生成代码并不是一次性的工作，当修改和完善，导致你的生成代码有了很多“沉积物”的时候，会往往需要重新生成代码来清洗这些“沉积物“，如果没有所谓的保护区，你就可以直接删除所有的生成代码全部重新生成了。
          使用扩展的方法，向生成代码里面添加扩展点，采用委托，接口，#include的方式，或者是使用反射，AOP模式，有些语言提供部分类(比如C#),这样我们能够使生成的代码文件与手写的扩展代码文件分割开来. 这样做也有缺点，如果你修改模型生成不同的代码，手动修改的代码并不会自动的相应重构（需要实践验证），另外这种主要会使代码的实现不断增加，编译时间也会增加.
          随着工具的不断改善，可能会有更多的可行的方法，不过到现在为止，添加扩展的方法是问题最少的。

           控制手写代码
           生成器生成了一些模型元素的抽象类，期望开发者实现抽象类并且要符合命名约定，但是如果我们只是生成，怎么才能提示开发者来实现自己的代码呢?
           如果具体的实现类被调用或者抽象方法被调用，在编译的时候会有编译错误，开发者根据错误的不同，实现自己的代码，但是这并不明显，因为还需要开发者去根据错误类型去排查。
           有两个方法解决这个问题:
             1. 对生成的代码生成约束和检查，能够由IDE调用评价代码，如果有错误，把消息报告给开发者，必须按照指定的方式实现了代码，错误才会消失.
             2. 有些时候生成的代码不会执行，由IDE直接调用缺失的部分。比如如果需要用户手写一个生成的子类，我们就可以生成以下这句:if (false) { GeneratedBaseClass x = new ManualSubclass() }.

          关注生成的代码
          不要以为生成的代码就可以扔掉不管了，与生成代码集成时，你将不得不看生成的代码，在一定程度上了解它，甚至在某些时候调试它。因些，要确保生成的代码文档规范，命名规范，代码缩进。其实这些在你的模板文件里都很容易实现，另外在生成的代码里写上需要的信息，以供后期查看。
         使生成的代码遵循和手写的代码相同的标准.
         在一些非常成熟的环境下，可以生成100%的代码，而不用再手写代码来扩展实现，在这种情况下，这里所说的这些就不适用了。

        保证生成的代码不偏离模型
        在许多情况下，需要实现一些约束来验证一些属性的正确性，为了确保模型的数据都由代码保存，使用以下两种方法:
         1.生成的代码不允许违背模型的承诺.例如：不暴露工厂允许组件查找和使用其它组件（直接创建依赖），而是要使用依赖注入提供合理的对象引用.
         2.使用结构分析工具（依赖检查器)验证手写代码，可以很容易从模型秋这些结构分析工具生成检查规则.

         视点级处理
         上面提到的视点不仅和模型设计有关，而且对于处理模型也很重要。有些时候可能需要单独的对不同的视点模型检查约束。有些视点可能更适合解释处理，而不是代码生成。当生成代码时，也可能会考虑基于视点分阶段生成.
         另外还需要注意，已经有了一个使用模型分区进行分割的机制，每个分区应该被单独处理。如果分区和视点一致，会很使得很容易处理。

         视点配置(未评级)
          对于使用视点和分区的系统来说，当模型处理器运行时，经常会有一些选项需要指定:使用约束的一些子集验证整个模型；仅仅生成子系统的业务逻辑代码；或者是生成针对生产环境的整个系统的部署代码.
          使用单独的模型来处理配置是一个不错的选择，这样为模型处理器绑定了“关注的范围”,通过处理”编译器配置”也作为一个模型，能够带来很多方便，生成模型数据到属性文件或者XML文件，使得更容易处理.

         关注模板
          代码生成模板是模型处理过程中核心资产之一，它包含着DSL表达的领域概念到实现代码的映射。随着时间，模板数量肯定会增加，维护起来会有一些问题,关注以下这些技术:
          1.把模板分成一些小的模板，相互调用.
            2.把一些通用的复杂表达式提炼成方法，能够被所有的模板调用。
          另外还有一个提示：模板文件只为自己提供缩进方式即可，对于生成的文件，可以直接全局使用代码格式化工具来处理。
          对于一个成功的框架生成代码，模板代码的需求总量减少，它们间的只有少数需要改进维护.

          M2M转换简化代码生成
          在一些情况下，使用一一个Model-to-model转换器代替代码生成，比如对于一个描述分层组件架构的DSL,大多数组件运行时平台不支持这样的分级结构，所以需要“扁平化”结构。在这种情况下，不要打算使用代码生成器，而且考虑先使用m2m转换，然后再写一个针对扁平没有分级模型的简单的生成器.
         在这里讨论的是模型转换中的单向转换，双向转换只在这里没有提到的极少数情况下使用。

使用M2M转换进行语义分析(未评级)
          model-to-model转换另外一个重要场景就是可以为了更好的语义分析,把一些模型转换成更容易理解,更容易验证,工具更容易支持的另外的模型.比如对于一个并发,分布式系统的行为描述,可以把它转换成Petri网,再使用合适的工具.

          允许适配
        为了使我们的模型驱动能够满足更多的项目, 要保证我能够以非侵入的方式直接适应一些调整:
           1. 我们可以为每个模型元素都添加哈希映射键值对,用于存放一些附加的信息，这些信息可以被模型处理的其它地方使用．
           2. 代码生成模板能够非侵入性的定制，直接支持生成不同的代码. 可以采用工厂和多态. 不这这个要权衡，没有必要所有的都需要做到允许调整，可以分为公有和私有，私有的模板就没有必要了.
          级联效应
          开始MD*方法时，可以先定义PIM模型，然后转换成少抽象，平台特定的PSM模型，最后生成代码.不过根据我的经验，最好是从底部开始，先定义一个DSL来描述系统的软件架构，然后定义一个生成器来自动完成和实现技术相关的繁重的工作。直接在DSL中对目标架构的架构概念抽象。
          接着在稳定的基本的抽象上建立特定的业务领域，可以使用M2M转换把更抽象的概念和架构语言中已经存在的抽象映射起来，把他们“喂”给已经存在的生成器.而对于不能够映射到底级的架构抽象提供特定生成器生成代码作为架构生成器视点的“业务逻辑实现”（取代之前必须手写的代码).
          注意永远也不要修改中间阶段模型，它们是用于传递的，通常甚至不被存储。他们是于你的级联级的各个阶段的”数据扩展形式”.如果你想在你的目标模型中添加信息，请使用注释模型。

         注释模型
          使用model-model 转换可能会遇到和代码生成同样的问题，有必要在更进一步地处理前手动标识转换步骤的结果，其中一种方法是在创建后经过一个转换来修改模型，不过这种方法会遇到和代码生成时的保护区一样的问题。
         更好的解决方案是创建一个单独的模型--注释模型, 直接引用中间模型中的元素,指定一些附加的模型数据,下游的处理器将处理由上游的model-to-model转换器和注释模型组合后的创建的模型.
         比如,你从面向对象数据模型创建关系数据模型,你可能自动地把OO模型的类的名称当成数据库中表的名字,如果你需要改变这些名字,使用一个注释模型指定一个备用名称,下游的处理器就知道注释模型中的名字覆盖了原来模型中的名字.

          分类行为
         为了更有效的实现行为, 把行为归类成几种,比如基于状态,或者基于业务规则. 为这些行为提供特定的DSL,在很多情况下,你只需要非常有限的配置参数就可以生成行为了.

          不要忘记测试
         在MD* 中,测试是很重要的环节.
         1.约束检查也是测试的一种形式,就比如程序语言中的编译器
         2.测试代码生成器的时候,不要测试生成代码的语法,直接编译代码,使用单元测试,测试代码的语义.
         3.针对转换的结果中的具体数据写一些约束检查来测试模型转换
         4.测试代码生成器,建立一个测试模型来测试语言的所有的功能,这是生成器开发者来做的,而不是生成器使用者.
         如果生成器经过完整的测试,相对成熟后,没有必要再用生成器在项目里测试生成的代码,不过仍然可以用单元测试测试整个系统.
         真正的生成系统和测试不要使用同一个模型,因为可能会导致在错误的系统上进行的错误测试反而测试通过.

       4.处理和组织
          迭代
         一些人借MD*来应用瀑布型,花几个月时间开发语言,工具和框架.这并不是一个成功的方法.而是应该采用迭代的方式. 可以先开发一小部来深刻理解,先建立语言的一小部分,构建一小部分生成器,开发一个小例子模型来验证所做的.然后再逐步来按照需求实现.
         概念与语言共同发展
        构建语言,使你更加清晰概念和理解领域.相辅相成.
         文档是必须的
        构建了DSL和模型处理器还不足够让MD*成功,还必须和用户沟通,让DSL和处理器能够使用起来,这时候就必须有文档来说明语言,编辑器,生成器,怎么来手写代码,怎么来集成等等.同样可以录制视频,截图,讨论都是不错的选择.
          定期评审
         DSL限制在某些方面限制用户的一些自由，只能在DSL的限制内表达事情。而且一些实现的决定并不是由DSL的使用者决定的，而是直接由模型处理器直接处理了。
         即使再好的DSL，用户仍然会犯错误，可能会滥用DSL。一定要定期Review,相当重要，也很关键。在Review中发现的经常性的错误，有可能就是使用者经常犯的错，我们就可以添加一个约束检查来自动检查这个问题。或许这并不是错误，而用期的是对的，这时候就可以适当地调整一个语言了。
          知人善任
           MD*里能够让大家都做最擅长的工作:
            1.对于目标技术专家，可以深入研究目标架构中的一些技术细节，研究的更深更透，这样才能够最佳处理方式，才能够把这些知识抽象成生成器模板，才能够复制起来广泛使用。他们只需要和生成器和语言设计者沟通就行了。
           2.语言设计者和领域专家一起定义抽象，符号，约束。和平台专家，架构师一起定义代码生成器或者是解释器。
          你必须确保你团队里的人都了解语言设计，知道领域对象和理解目标平台，都要有MD*这此思想，否则MD*方法就不会成功.
         领域用户需要写程序吗？
            域用户并不是程序员，他们只是描述领域知识，如果让领域用户理解你的DSL,可能并不是他们的过错，而你的语言不适合这个领域，这时候需要一直关注了。
         领域用户 vs 领域专家 (未评级)
             建立DSL时这两个角色可以发挥不同的作用，领域专家参与领域分析和DSL本身的定义，域用户可以使用DSL来表达具体的领域知识。
          元数据级产品
             一般是少部分人开发的这些语言，约束，生成器，被多部分人来使用。这需要建立好的机制，需要时不时地就让生成器的部分开发者直接参与实际的开发项目，让他们了解这些是否真的适应实际的应用。
   兼容组织
            MD*可能需要跨项目工作，应用在多个项目和环境下时，需要很好的处理好跨领域。
         忘掉发布的真实案例
           许多新的软件开发方法通过发布案例来宣传，虽然通过例子来展示一些用处，但是并不根据案例就做出真正的决定。来决定DLS和MD*是否适合的唯一方法就是做一个原型。

      5   开放的问题
            在我们结束这个最佳实践的时候，还有一些悬而未决的问题，为此，社区和工具提供商必须找到让人满意的解决方法:
              (1)混合符号,没有可用的工具直接支持把文本符号直接嵌入在图形模型中. 或者使用类似公式化的编辑器,半图形语法构建DSL. 软件有这方面的趋势,但是工具还跟不上.
              (2)语言模块化和组合在某些环境下也是一个挑战, 尤其是文本语言,基于解析技术,组合解析需要不太好处理, Jetbrains的MPS把文本模型作为元数据结构存储是有优势的, MetaEdit+在语言模块化方面处理的非常好.
              (3)元数据级的重构在大多数系统中是不支持的. 这个其实没有太大的挑战,我认为只是还没有人做.
              (4)模型/代码重构就没有这么简单. 对于依赖于从模型自动生成代码,而手写的自己的代码,如果修改模型,重新生成代码, 怎么处理手写的代码? 经常是不做任何处理, 而理想情况下是希望手写的代码能够自动改变,能够直接适应模型的变化
              (5)模型自动迁移也是一个没有解决的问题. 你的语言变化后你将如何处理你的模型? 全抛弃他们,因为他们已经不能够再打开了? 在新的编辑器打开他们,但是原来模型中的一些标记与新语言不兼容?自动尝试迁移? 这些都是可选择的方案,但是真不知道最好的做法是什么样子.
              (6)模型调试即在模型级别上调试正在运行的系系统. 虽然你可以手工构造特定的解决方案,但是还没有工作直接支持这样的调试器的实现.
              (7)解释和代码生成通常被认为两种选择,而不是一个统一体. 你可能需要的只是一个解析器,那么你可以在解析器比较慢的地方部分选择使用代码生成.只还在研究中,没有可用的处理.
              (8)处理庞大的模型,或者是模型数量过多时也是一个问题.如何扩展基础的架构?在一些东西改变后如何做影响分析? 如何导航浏览大而多的模型?如何有效率地搜索和查询他们?如何逐步地呈现他们?
              (9)生成的模块如何组合? 如何定义这些模块的接口?如何这些模块已经间接依赖于你生成的代码了,该如何处理?

          太多挑战了,让我们开始吧!

     [翻译] DSL和模型驱动开发的最佳实践(1/4)
     [翻译] DSL和模型驱动开发的最佳实践(2/4)
     [翻译] DSL和模型驱动开发的最佳实践(3/4)

原文: http://www.jot.fm/issues/issue_2009_09/column6/index.html
由于篇幅太长，所以分几部分翻译。翻译水平有限，如果英语不错，最好直接阅读原文.
向模型驱动开发的同学们强烈推荐此文!

作者：孤独侠客（似水流年）
出处：http://lonely7345.cnblogs.com/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

本文链接

[翻译] DSL和模型驱动开发的最佳实践(3/4)

2010-04-06T03:15:00Z

    哪个是最佳选择
   有两种风格的语言设计:一种主张大语言,用一个类支持许多不同的领域概念.另外一种主张小语言,使用一些小但是强大的原始的特征,大一些的特征由库的方式组装构建．
     在构建DSL的时候需要一直记住的是：确认你的语言设计始终保持一致．你保持上面两种方法思想中的一个.使用第二个方法会更复杂，并且需要花费比较大的努力发现这些基本的原始特征．尤其对于业务领域DSL,第二种方法基本会失败，因为业务用户并不习惯于使用新的，强大的，正交概念．
      用容易确认地，众所周知的概念定位DSL，一定要保证这些概念是最佳的选择，并且使用合适的符号，例如，在移动手机开发的DSL中，确信你的最基本的都是可输入的原子（左键，右键，0..9数字键，操纵杆).不要尝试抽象成通用的”输入设备”.
     你也可以组合这两种方法，然而，确认你的语言保持一致性和完整性。

    库 Libraries
    前面的最佳实践提到的一个概念就是Libraries的使用。Libraries是你的DSL的一些实例的集合，主要用于重用，一般存储在单独的模型分区中.
      Libraries很明显有助于重用模型数据。例如，在一个用于描述数据结构的DSL里,经常就会把一些重用的数据结构放到一个Libraries里提供给其它使用（比如date,time,address，另外Libraries就是分区的一种形式).
      Libraries也用于降低语言的复杂性，考虑上面提到的数据结构DSL:代替直接硬编码原始类型int,string,bool,你可以实现一个原始类型构造器生成int,string,bool类型实例。这样也能够允许用户添加直接通过修改模型添加新的原始类型，而不是直接修改语言，这能够减少不少麻烦.
      如果你使用library方法，保证模型处理器没有假设更高层次的结构构造，取代的是真正的基于基本的原始特征。在我们的例子里，映射的原始类型对应着目标语言(比如java)，这需要作为模型的一部分，否则当你通过类库添加一个新的原始类型的时候，还需要修改代码生成器。

      团队支持
     DSL工具很重要的一个方面是支持版本，标签，分支，锁定，比较和合并，协助操作模型的所有方面。确保你使用的工具支持所有这些，使用语言的具体语法，没有人愿意用抽象的语法/元模型/树层次来处理这些问题。
      当面对业务专家，基于资料库的系统是非常有能力解决这些问题的，然而，当你直接面对开发者时，模型必须与其它的开发工具进行互操作。尤其是你需要与现有的源代码控制系统集成时(CVS,SVN,Gitt等)。再者，如果你的系统是模型特定的或者是手写的3GL代码，必须能够加标记，对两个文件进行比较和版本控制来防止带来灾难.一个明确资料库的工具在这种场景下如果它并不提供集成资料库代码的方法的话,会有比较大的问题.
      文本DSL在这方面有明显的优势, 讲到这里为止,模型还只是文本(至少他们存储为文本文件,并且文本符号是潜在的数据存储结构).
      就商业用户而言,悲观锁定(没有必要进行比较和合并)可能更容易理解.通常在悲观和乐观方法之间做选择的时候,应该基于处理的过程和收集的用例.
      好的分区能够使团队支持更加容易, 分区实际上成为比较,合并,锁的基本单位.

   工具细节
     定义语言和符号本身是不够的,你还必须为他们提供良好的工具支持.
       DSL的编辑需要能够支持团队工作（见上文），导航，全局查看，搜索，快速查找，查找引用，显示被使用处，甚至重构。对于文本的DSL，你的编辑器必须提供代码完成，语法高亮等，以确保发展人员（使用强大的集成开发环境开发”正规”语言的人）愿意使用DSL工作。
      对于“元数据开发者”也是一样。请确保您的环境提供好的用户体验, 比如编写转换和代码生成，为这些提供了元模型感知编辑器。
      为了提高可用性，DSL的编辑器必须能够应付由用户输入导致的异常或不完整的模型。理想情况下,出现这种情况后,可能还需要持续。不过,只要模型是错误的或不完整，他们无法处理任何进一步。对于文本语言的环境下，这可能意味着你设计一个有点“松散”，更宽容的语法，通过约束来保证执行的正确性。
      您还必须确保该模型处理器能够运行在不间断生成（外部的编辑器或工具的一部分）来集成到现有的基础环境中。

[翻译] DSL和模型驱动开发的最佳实践(1/4)
[翻译] DSL和模型驱动开发的最佳实践(2/4)

本文链接

[翻译] DSL和模型驱动开发的最佳实践(2/4)

2010-04-02T05:13:00Z

上一篇: [翻译] DSL和模型驱动开发的最佳实践(1/4)

视点ViewPoints
     一个软件系统通常情况下只用一个符号是不可能描述他所有的方面的, 此外,为了开发流程的需要,不同的方面,在不同的时间里,会被不同的角色描述,因为你要保证有一个干净的概念分离.因此,最重要的是找出描述一个系统不同概念的这些视点,为他们单独提供表现符号和抽象.
     在一些系统中意味着你要为不同的关注点定义单独的DSL, 另外的情况下,你可以为一个DSL语义定义一些片断,每一个对应一个视点.
     无论你的工具支持哪个方法, 视点需要能够联系到另外的描述整个系统的视点,确保这些”连接点”是显示定义的,并且有数量限制, 另外,要确保这些视点之间依赖的方向是明确的--强烈建议使用单向依赖进行严格分层.
     注意这和软件系统的模板化很类似的, 相同的规则应用,强制的内部一致性,少量的外部接口,尽量少的耦合.

分区Partitioning

和软件其它部分一样,DSL编辑器和模型处理器不能够随意扩张,在你从一个小规模的原型开始一个项目的时候往往会忘记这点.在大多数情况下, 我们可以把整个模型划分为单独的”模型单元”.
     分区会影响到很多方面,分区可以作为签入/签出或者锁定的单位, 另外,经常直接引用一个分区,也可以通过代理实现跨分区引用,(工具强制)名称引用或者延迟加载. 分区在本地的限制是经常在编辑器里进行实时检查,全局限制是仅仅可能只按需检查, 这可能是全局编译过程的一部分.
     当然, 确保每个分区是单独处理是很有意义的,否则, 可能就需要明确区分哪些分区应该在在给定的处理运行的时候处理(至少可以通过查询路径,目录结构能够找到需要处理的分区,就象C编译器里的include路径一样). 你甚至需要考虑一个单独的编译步骤来合并多种分区的单独处理过程中的结果(就象C编译器,把每个文件都单独的编译成一个目标.obj文件,然后通过symbol/reference进行全局链接).
     在很多工具里,分区并不是完全透明的.你可能必须明确的分区,或者你必须确保你不会意外地创建对于其它分区的依赖.因此,最好在DSL和生成器开发过程中就考虑到分区,能够相应地设计元数据.
     可行的分区策略设计是语言设计的一部分!记住在这个背景中:哪个分区改变会导致模型的特性变化(比如元素名称改变会导致改变所有其它分区中通过名称引用这个元素地方发生改变), 在哪里存储链接(经常保存在模型中的逻辑指向另外一个的地方吗?),如果不是这样,如何/在哪/什么时候来控制引用和链接存储.
     分区是真正地物理的分割整个模型,它可以与逻辑模型结构或者视点结合起来(比如命名空间),也可以不结合.比如一个描述计费子系统的分区可能包含嵌在多个命名空间中的元素,覆盖多个视点(数据结构,流程,UI定义).

演变 Evolution

      在开始一个MD*项目时容易被忘记的重要一点就是语言演化的必要性。如果你改变语言，确信你已经有办法调整模型处理器和已经存在的的模型。
      这需要以下列出来的一个或多个：严格的配置管理控制，模型中的版本信息用来触发兼容的模型处理器，多层模型处理的撤销，能够把基于老语言的模型转换基于新语言的模型的模型迁移工具。
      模型迁移是否容易很大程度上取决于工具, 有些工具能够使模型非常平滑地演变,但是有些环境并不是这样.在决定使用哪个工具的时候一定要考虑到这点. 注意如果是文本DSL, 模型迁移至少可以通过正则表达式和grep来完成。
      一定要尽量减少对现有模型进行的改动，向后兼容和折旧是在MD*领域值得铭记的两个技术，你可以用你的模型处理器来收集有多少被弃用的语言特征仍然在使用，到模型中看不到有使用的时候，你就可以安全地把这个废弃的语言特征给移除了。
      完美隔离多个视点的DSL，防止一个DSL的一些地方修改时，引起所有模型的连带影响。

通用语言的谬误

预定义的通用语言和生成器都是都是诱人的--尤其是如果你想描述你的系统的技术方面。毕竟你可以使用UML模型一切，其实只是添加了一堆原型和标记值。
     应该小心地是，使用预定义语言会使你花费大多数时间在思考如果把你的领域概念硬装进现有的语言。同时，你还不得不考虑到现有语言的抽象和符号。当然，一些通用语言提供了适配功能，比如UML的Profile。至于在现在的实用工具里面，UML还是一直很受欢迎的。你必须添加一些限制来防止用户在你的领域模型里使用一些没有意义的UML功能.不过，你的语言经常会比较像UML,定制的UML工具的实际实用性是远远不够的（注意：符号！符号！符号).最后，你的模型处理器必须处理大而复杂的UML元数据－－Profile经常添加，并且从不删除任何东西。
    在实践中，在大多数情况下，最好是定义你自己的DSL, 最初他可能需要多一点工作量，但是不久他就会变得更有效率。
    但是，确认你没有重新发明轮子。比如，没有必要重新彻底改造状态图和时序图，UML在这方面已经相当不错了。不过，对于一个有用的UML符号有小的改变，Profile机制是不错的选择。
    所以，如果已经有比较合适的通用语言了，直接使用存在的语言，尽量确保你自己的实现是兼容的(duck modeling:如果它看起来象状态机并且具有状态机一样的行为，那么就是一个状态机^1).

    学习3GLs
     上面我们讨论了一个事实，那就是DSL不是一个变相的通用语言。然后，DSL仍然可以学习现有的形式和语言。
     这里有四个例子:
     1.许多语言需要某种范围的概念：对于模型元素上的一个给定的引用，只有类型兼容的模型元素的一个子集构成了这个引用有效的目标。
     2.特性不仅可以应用在面象对象里的类上，同样适用于状态机，或者保险合同规范。
     3.命名空间的概念在许多DSL里出现，用来组织模型元素的命名方案.
     4.许多DSL有实例的概念，能够表达一些概念是其它概念的一个实例，有效地引用内置语言类型系统，作为你的约束检查的一部分，你可能需要做类型计算和类型检查。
     要成为一个优秀的DSL设计者，有比较广泛的现有编程语言范式的知识是很有用的，请读这本书《Concepts, Techniques and Models of Computer Programming》。

本文链接