我正在使用PetaPoco微型ORM。使用ORM工具处理数据库确实非常容易且安全，但是我唯一讨厌的是额外的代码。我曾经将大多数代码放在数据库本身中，并使用了所有RDBMS功能（如存储过程，触发器等），这些功能旨在更好地处理。
我想知道何时不对存储过程/触发器使用ORM，反之亦然。
Answers:
ORM（对象关系映射）与存储过程不互斥。大多数ORM可以利用存储过程。如果您愿意，大多数ORM都会生成存储过程。因此，问题不是非此即彼。
ORM可能会生成不可接受的SQL（就性能而言），您有时可能希望使用手工制作的SQL覆盖该SQL。实现此目的的方法之一是使用SP（存储过程）。
在DotNet中，如果满足以下条件，则不要使用存储过程：
如果您不熟悉存储过程（不是您的情况，而是出于完整性考虑而包括在内）。
如果您不想在您的项目中引入一层复杂性并实现多功能化。
您正在创建一个应与其他数据库一起使用的应用程序，或者必须在多个数据库服务器之间复制的应用程序（此最后的限制可能仅适用于某些数据库）。
请注意，不要将触发器与ORM进行比较。触发器执行的功能最好不在应用程序代码中（例如，跨数据库记录或同步数据）。
有些人出于各种原因（例如安全性（例如，防止SQL注入）和声称的速度）而不喜欢在代码中使用存储过程而不是SQL。但是，这有点值得商and，需要详细讨论。
如果您的ORM无法生成存储过程，而您必须编写一个大型系统，那么您需要根据情况来权衡额外的手工编码。
ORM 通常假定存在数据库来为ORM服务。但是通常数据库是为公司服务的，公司可能会用多种语言编写成百上千的应用程序。
但是，如果您使用的是无法调用存储过程的ORM，则这只是“ ORM与存储过程”的一种情况。否则，就需要确定在哪里编写业务逻辑代码。
无论您在何处编写业务逻辑，其工作都是确保数据库从一种一致状态变为另一种一致状态，而不管是哪个应用程序进行了更改。因此，您实际上只有两个实际选择-在数据库中对其进行一次编码，或在“不可渗透”的数据访问层中对其进行编码。
如果使用“不可渗透”的DAL，请注意dbms命令行界面。
触发器应用作记录的不变式，或由重要的业务规则（恕我直言）组成。
orms的问题：