ObjectDataSource中DeleteMethod的软弱

做三层时对一个Model一般对其Delete方法都会行如下建立：

        /**//// <summary>
        /// 删除一条数据
        /// </summary>
        public static void Delete(int AlbumID)
        {
            DataBases.EntityBase.Delete(DB.Albums).Where(DB.Albums.AlbumID == AlbumID).Execute();
        }

个人正式开放中没有使用ObjectDataSource的，测试时图省事拖个东西来用，以前没在意都是看看Insert草草关掉，今天就点了一下Delete竟然抱错！未能找到接受“WrestSoftPersonalWebSite.Module.Albums.Album”类型的参数的非泛型方法“Delete”

诶？怎么回事？

ASPX：

    <asp:ObjectDataSource ID="ObjectDataSource1" Runat="server" TypeName="WrestSoftPersonalWebSite.Module.Albums.Album" 
        SelectMethod="GetList"
        InsertMethod="Add" 
        DeleteMethod="Delete" 
        UpdateMethod="Update" DataObjectTypeName="WrestSoftPersonalWebSite.Module.Albums.Album" >
        <DeleteParameters>
            <asp:Parameter Name="AlbumID" Type="Int32" />
        </DeleteParameters>
    </asp:ObjectDataSource>

鼓捣了一阵也没有什么斩获……

MSDN翻翻吧：
ObjectDataSource.DeleteMethod 属性 中看到如下：

方法解析
调用 Delete 方法时，数据绑定控件中的数据字段、DeleteParameters 元素中以声明方式创建的参数和 Deleting 事件处理程序中添加的参数全部合并在一起。（有关更多信息，请参见上一节。）然后，ObjectDataSource 对象尝试查找可以调用的方法。首先，它查找具有 DeleteMethod 属性中指定的名称的一个或多个方法。如果没有找到匹配项，则引发 InvalidOperationException 异常。如果找到了匹配项，它随后将查找匹配的参数名。例如，假设 TypeName 属性指定的类型有两个名为 DeleteARecord 的方法。一个 DeleteARecord 带一个参数 ID，另一个 DeleteARecord 带两个参数 Name 和 Number。如果 DeleteParameters 集合只包含一个名为 ID 的参数，则调用仅带 ID 参数的 DeleteARecord 方法。解析方法时不检查参数类型。参数的顺序无关紧要。 

如果设置了 DataObjectTypeName 属性，将以不同的方式解析方法。ObjectDataSource 查找具有 DeleteMethod 属性中指定的名称的方法，该属性带 DataObjectTypeName 属性中指定的类型的一个参数。这种情况下，参数的名称无关紧要。

这是什么意思，只能建立一个参数为DataObjectTypeName 的Delete方法了？（当然了，MSDN中给出了范例是处理ObjectDataSource的ondeleting和ondeleted，意义不大了，要你就是图省时间，反而慢了我就不要你了嘛……）
回到BLL里又重装了一个：

        public static void Delete(Album model)
        {
            DataBases.EntityBase.Delete(DB.Albums).Where(DB.Albums.AlbumID == model.AlbumID).Execute();
        }

编译DLL后，再此尝试执行删除，无异常产生！如MSDN所述，<DeleteParameters>的存在并无意义！

唉…… ObjectDataSource由此还是有点软弱的，对于重载的选择支持不好。

不知道众高手是否有破解之道…… 当然，实际开发中是很少用到这个的如果不是为了技术攻克，意义就不大了。