dotnetnuke 的自定义业务对象类可以进行哪些改进？
我在一些项目中从事 DotNetNuke 工作，我发现非常有趣的自定义业务对象类，其名为 CBO.vb。
所以我想在我的其他项目中使用这个帮助器类，该项目不在 DotNetNuke 中，而是在 core asp.net 项目中。
所以我读到了这个类的一些重要方法，我主要使用的是：
- CBO.FillObject
- FillCollection
现在我正在搜索这个类中有哪些可以改进的问题在我要使用这个课程之前由我进行。
所以我搜索这个并在 代码项目 上发现了一个有趣的主题，其中指出了几个问题如下：
- 业务对象和数据库中的字段必须具有相同的名称
- FillCollection 方法返回一个 ArrayList
所以我的问题是在使用之前还有其他可以解决的问题就像
使用反射创建速度较慢的对象，因为它们给出如何实现的想法 通过使用IHydratable Interface
你可以找到此处类
I worked on DotNetNuke in some projects and I find very much interesting Custom Business Object Class which is named as CBO.vb in the DotNetNuke project.
So I want to use this helper class in my other project also which is not in DotNetNuke but in core asp.net projects.
So I read about some important methods of this class which are majority used by me are:
- CBO.FillObject
- FillCollection
Now I am searching what are issues in this class that can be improved by me before I am going to use this class.
So I search this and found an interesting topic on code project which point out several issues like:
- business object and the fields in the database had to have the same name
- FillCollection method returned an ArrayList
So my question is there any other thing which can be solved before use like
use reflection to create objects which are slower for that they give idea how to implement this by using The IHydratable Interface
You can find class here
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
CBO 是一个有用的类。但是，如果我今天正在寻找类似的解决方案，我会寻找一种新的“Micro-ORM”，例如：
大量
PetaPoco
Dapper
当在数据库周围应用这样的轻量级包装器时，我不确定是否支持不同的数据库和业务对象中的名称确实是个好主意。这可能是造成混乱的一个原因。
此外，FillCollection 方法已经有返回
List的通用重载。 ArrayList 版本只是为了向后兼容，任何人都不应该用它们编写任何新代码。CBO is a useful class. However if I were looking for a similar solution today, I would look to one of the new "Micro-ORMs" such as:
Massive
PetaPoco
Dapper
When applying such a light wrapper around the database, I am not sure that supporting different names in the DB and business objects is really a good idea. It is a likely source of confusion.
Also there are already generic overloads for the FillCollection method which return
List<T>. The ArrayList versions are only there for backward compatibility, no one should write any new code with them.