业务对象和动态 SQL
我有这个想法，得到这个想法后我的第一反应是“这是一个好主意，但为什么我以前从未见过/听说过它？”所以我希望你能告诉我是否有一些框架已经做到了这一点，或者是否有某种原因我应该避免它。
这个想法是创建一个基本业务对象类，其中包含基于派生类的名称及其属性（或属性中指定的别名）动态编写 CRUD sql 查询的方法。
我的想法是，一旦我这样做了，我就可以像这样创建一个新类：
class Customer: BusinessObjectBase
{
int Id {get;set;}
string Name {get;set;}
string Phone {get;set;}
}
并且我的 Customer 类可以访问 BusinessObjectBase 的 CRUD 方法，就可以完成。
回答这个问题时需要记住一些事情：对于这个问题，我对减少开发时间和低维护的设计目标非常感兴趣，并且安全性在 1 到 10 的范围内约为 3。换句话说，我不想听到答案告诉我应该使用存储过程来访问数据，因为它们更安全，或者类似的东西。
我知道这里的用户在涉及过于广泛的问题时非常自由，投票结果很接近......所以为了安全起见，让我重申一下这个问题，这个问题不太广泛：
是否有任何现有的框架可以做到这一点，或者是否存在有什么令人信服的理由让我不应该这样做吗？
I had this idea and my first reaction after having it was "That's a great idea, but why have I never seen/heard it talked about before??" So I'm hoping you can tell me if there is some framework out there that already does this, or if there is some reason why I should avoid it.
The idea is to create a base business object class with methods to dynamically write CRUD sql queries based on the name of the derived class and its properties (or aliases specified in attributes).
My thinking is that once I do this I could just create a new class like so:
class Customer: BusinessObjectBase
{
int Id {get;set;}
string Name {get;set;}
string Phone {get;set;}
}
and my Customer class, having access to BusinessObjectBase's CRUD methods, would be done.
Somethings to keep in mind when answering this: For the sake of this question I'm highly interested in the design goals of decreased development time and low maintenance, and security is about a 3 on a scale of 1 to 10. In other words, I'm not interested in hearing answers telling me I should be using stored procedures to access data because they are more secure, or anything along those lines.
I know the users here are pretty liberal with the close votes when it comes to overly broad questions... so just to be safe let me reiterate the question, which is not too broad:
Are there any existing frameworks to do this or is there any compelling reason why I should not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
以前已经做过了；很多次，很多方式。您想到的基本概念称为“模型优先”开发。您可以首先在 Entity Framework、NHibernate、Subsonic 和许多其他 ORM 风格框架中进行建模。这种思路的另一个体现是 LINQ-to-SQL，其中 LINQ 知道要生成哪些查询，无论您是否有 CRUD 存储过程。
在 ORM 成为主流之前，我们使用代码文件（现在以 T4 样式模板进行编码）来写出您的描述。整个想法基于“约定”，这意味着如果一个字段被命名为 ID，那么它一定是 clustered-PK，依此类推。
免责声明
话虽如此，这种思路也有缺点。在典型的 Web 应用程序（或在此处插入您的应用程序样式）中，您需要使用三层——客户端、中间层和数据库。通过模型/代码优先开发，您实际上忽略了三层之一。现代硬件已经变得足够快，您可以为大多数站点执行此操作。当您的网站数量增长时复杂性，但是，您经常会发现自己正在为最复杂/最常用的场景解决此自动增删改查设置。
无论如何，希望有帮助。
It has been done before; many times, many ways. The basic concept your thinking of is called 'model first' development. You can do model first in Entity Framework, NHibernate, Subsonic and many other ORM style-frameworks. Another incarnation of this line of thinking is LINQ-to-SQL where LINQ knows what queries to generate, whether or not you have CRUD stored procs.
Before ORM's were mainstream we use code files (codified in T4 style templates these days) to write out what your describing. The whole idea was based on 'convention' meaning if a field is named ID then it must be the clustered-PK and so on.
Disclaimer
With that said, there is a down side to this line of thinking. In your typical web app (or insert your app style here) you have three layers to work with--- client, middle, and DB. With model/code-first development you are effectively ignoring one of the three layers. Modern hardware has gotten quick enough that you can do this for most sites. When your site grows in volume & complexity, however, you will often find yourself working around this auto-crud setup for your most complex/frequently-used scenarios.
Anyway, hope that helps.