Magento(社区版)自带模块解析以及在国内的使用建议一

本章开始逐个解析Magento1自带的模块，根据模块复杂度和重要性的不同，描述的方式也会有所区别，有些仅使用文字，有些会配上截图。

1、Admin

如字面意思，Admin模块是跟后台管理员相关的，具体来说，主要就是后台用户（admin_user表）和后台用户的权限管理（admin_role和admin_rule表）。到1.9.2.3版本，

出于安全考虑新增了permission_variable和permission_block功能，这个就不细讲了，详见1.9.2.3的release-notes。

这里扯远一下，Magento的权限功能是基于ACL模型的，市面上还有另外一个应用广泛的访问控制模型叫RBAC。虽然ACL一般情况下也可以满足Magento后台管理的需要，但结合以往实际工作中碰到的情况来说，RBAC模型可能更符合一个电商网站后台管理的需求，比如出现“客服主管”和“普通客服”这种层级结构的权限分布要求时。

毫无疑问，这个模块是必须开启的，后台的基石。

2、AdminNotification 

字面意思是后台的通知，这个模块的实际作用差不多也就是这个意思。通知的展示形式分钟两种，一种是通栏方式显示在后台主菜单栏下面，另一种方式是登录后台时以弹窗方式出现。

通知的内容大概有以下几种：网站运行状况（比如缓存过期，索引未更新等等），Magento官方推送的通知（比如有新版本，官方要举办什么活动等等），安装的第三方插件所属公司推送的信息（比如安装的插件有新版本，或者如上图这类推销打折信息）。

AdminNotification模块理论上可以关闭，不会影响网站前后台的正常运行。关闭之后上面提到的这些通知你将不会再收到，避免了骚扰同时也失去了得到有价值通知的功能，当然失去通知也不会有多大影响，比如关注Magento的人自己本身就会时不时关注官方是否有新版本发布了。

所以，这个模块关闭与否，可选。

3、Adminhtml

Adminhtml是一个庞大无比的模块，整个目录下有超过500个文件夹和超过1000个文件。虽然如此庞大，这个模块的作用却很好解释，那就是几乎整个后台所展示的内容（不算第三方插件）都由Adminhtml来控制。

这里有一个代码结构上的疑问，Magento把功能按模块划分的做法是受大部分人认同的，对降低整个系统的耦合度相当有益。唯独Adminhtml模块把所有功能的后台管理部分集合在了一起，把这个模块变成了一个庞然大物。理论上Magento可以把不同功能块的后台管理的代码写到各自的模块目录下面，比如商品后台管理的代码可以写到Catalog模块里去，这样子看上去系统的模块化就更彻底了（比如第三方插件如果有后台管理的部分，后台的代码自然是写在自己模块的目录下的）。

Magento官方这么做也许有自己的考量，至少对于后台的修改和二次开发来说，可以在一个模块里找到所有后台源码也是一种便利。

Adminhtml模块当然是必须开启的，不开就没后台了。

4、Api

Magento的第一种类型的接口模块（早期的版本只有这一种类型），提供XML-RPC和SOAP两种接口协议，这两种协议一脉相承，对于已经封装过的Magento来说，新增一个接口只需要开发一套代码，就可以同时支持XML-RPC和SOAP两种协议。

  SOAP是一套虽然已经不年轻，但依然被广泛使用的接口协议，基本上所有流行的编程语言都有现成的支持SOAP的类库。

  除了对协议的封装，Api这个模块提供了基于ACL模型的接口资源权限分配，可以通过后台来按需指定不同接口用户拥有不同的访问权限（比如A用户只允许访问1、2、3接口函数，B用户只允许访问4、5、6接口函数），这个对网站的信息数据安全相当有好处。

  Api模块不是必须开启的，如果没有对外开放接口的需求的话。当然，实际运作中的Magento网站，应该很大比例都会有跟其他系统对接的需求，这个时候，经过系统底层的封装之后，在Magento上开发新接口还是很方便的。

 

5、Api2

Magento的第二种类型的接口模块（后期版本新增的），提供REST风格的Api接口支持。

与Api模块类似，Api2模块同样对接口进行了封装，以及同样提供了通过后台进行接口资源权限分配。

        针对REST风格的Api的授权，Magento采用流行的oAuth协议来实现，这一点在系统里是通过另一个模块来配合的，这个模块的名字就叫做Oauth。

同样道理，Api2模块开启与否是可选的，取决于你是否会需要用到系统对接。Api2模块与Api模块之间没有相互依赖关系，可以自由选择单独用、一起用或者两个模块都不用。

6、Authorizenet

      authorizenet模块非常好理解，就是一个美国本土的支付网关（类似paypal，详见http://www.authorize.net/）。不太清楚authorizenet在美国的流行度如何，肯定没有paypal流行。如果是做国内中文站的话，就肯定用不到这个模块，果断关闭吧。

7、Backup

Backup模块在后台提供了可视化界面用于给网站做备份，可以选择备份（及还原）网站文件或者备份数据库等等。备份生成的文件会放置在var/backups目录下。

常见的网站备份操作，一般是由运维人员通过在服务器上通过计划脚本来操作的。虽然Magento的Backup模块也提供了通过系统的cron机制来定时备份数据的功能，但能直接通过后台操作就能备份（特别是还原）网站，感觉上会不太安全（虽然也可以通过后台权限来控制一般后台用户无权操作），我个人是不太推荐这种方式的。

如果你不需要备份网站，或者如上所言把备份网站交由运维来操作了，那就把这个Backup模块关了吧。

8、Bundle

Magento原生提供了6种商品类型，捆绑商品（Bundle Product）是其中一种。6种类型里，Bundle Product和Downloadable Product是各自独立一个模块控制的，其他4个类型都在Catalog模块里面。

Bundle Product与另一种类型Grouped Products类似都提供了组合打包购买商品的功能，不同之处在于

Bundle Product提供了更复杂的组合方式，以及自由设置组合后商品价格（比如上衣加裤子组合买比单买优惠20等等）。详见：Magento grouped vs bundle products

捆绑商品的功能在蛮多场景还是用得到的，当然这个也看网站具体卖的商品类型（衣服还是食品）以及销售方式。这里有一个问题是，捆绑商品功能所能捆绑的对象只能是简单商品（Simple Product），而实际应用中好像有许多把几个Configurable Product捆绑卖的需求。PS：好像有第三方插件可以满足这个需求

如果确实不需要或者暂时用不到这个功能，可以把Bundle模块关闭（这个时候就体现出把捆绑商品单独拎出来做成一个模块的好处了）。

9、 Captcha

验证码模块，可以用于后台的登录和找回密码。

原生情况下只能用于后台（不排除二次开发之后用于前台）。关于这个模块开启与否的建议，我不太清楚老外的审美是咋样的，至少在国内来说，跟国内网站上常见的验证码相比，Magento的这套验证码生成的图真的是有点丑。所以如果不用这个功能的话，就把Captcha模块关了。如果确实需要用到验证码（我指的是国内），建议找一个更符合中国人审美的验证码类库，自己基于类库在Magento上做验证码的功能。

10、 Catalog

电商几大基本组成元素之一的“商品”（还有用户和订单），主要就由Catalog模块来控制。稍微具体来说，这个模块管理着包括分类，商品，商品属性等内容以及前台大部分跟商品展示相关的控制代码。对于Magento系统来说，这是一个核心模块，也是所有Magento用户最熟悉的几个模块之一。我这里只是对模块的概述，所以针对 Catalog模块反而好像没有什么需要特别拎出来讲一下的东西了。

Catalog模块当然是必须开启的。

以上是本系列的第一篇内容，简单总结下上面10个模块，

其中Admin，Adminhtml，Catalog三个模块是必须开启的（网站正常运行的基础），

AdminNotification，Api，Api2，Bundle是可以根据需求自选要不要开启的，

Authorizenet，Backup和Captcha我的建议是关闭（针对做国内中文站）。

之前有提过本系列是一个概述，所以对大部分模块的描述都是走马观花式的，因为每个模块要讲清楚的话都可以单独写成一篇文章（甚至多篇文章）。上面十个模块的描述都是基于我的个人理解，如果有描述不正确的地方，欢迎指正。