当前位置： 文江博客话题详情

我需要知道将业务层保留在程序中的缺点

发布于 2024-08-21 11:14:02 字数 191 浏览 7 评论 0原文

在我的工作中，我有一个朋友坚持使用存储过程将业务逻辑保留在数据库中......

我可以用什么论据来说服他不要做这样的事情？

他想要这样做的原因是因为我们有多个具有不同平台的系统（.NET 中的 Web 应用程序和 VB.NET 以及另一个在 Power Builder 中开发的桌面应用程序 - Sybase）。

谢谢！

原文

In my work, i have a friend that insists to keep the business logic inside the database using stored procedures ...

What are the arguments that i can use to convince him not to do such thing?

The reason he want to do this is because we have multiple systems with diferent plataforms (Web Application in .NET with VB.NET and another Desktop Application developed in Power Builder - Sybase).

Thanks!

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（5）

爱情眠于流年 2024-08-28 11:14:02

我可以用什么论据来说服他不要做这样的事情？

你反对的理由是什么？为什么您一定要远离存储过程？

这实际上并不是一个坏主意。如果您有用不同语言编写的不同系统访问数据库，那么将至少部分业务逻辑保留在数据库中可能会有所帮助。

What are the arguments that i can use to convince him not to do such thing?

What are your arguments against it? Why do you necessarily want to stay away from stored procedures?

This is actually not a bad idea. If you have different systems written in different languages access the database, it may help to keep at least some of the business logic in the database.

回复 原文
七堇年 2024-08-28 11:14:02

我选择 Web 服务有几个原因：

  • 您可以将您的服务公开给所有类型的客户端来使用它
  • 它更灵活，更方便调试，用于测试
  • 您将获得更好的源代码控制支持
  • 您的编程语言可能比 SQL 更具表现力

I would go for the web service for several reasons:

  • You can expose your services to all kind of clients to use it
  • It's more flexible, more convenient for debugging, for testing
  • You will gain a better source control support
  • Your programming language will be probably more expressive than SQL
回复 原文
吐个泡泡 2024-08-28 11:14:02
  • 不是强类型的。
  • 无法轻松重构，在运行时破坏客户端。
  • 不可进行单元测试。
  • 很可能并非所有业务逻辑都可以是存储过程，因此您的逻辑分为数据库和代码。
  • 存储过程不像编程语言那样有能力或强大
  • 更难获得正确级别的封装，要求您的客户端了解数据模式的内部结构
  • 更难以版本化
  • 业务逻辑与数据库供应商相关联，而您将陷入困境生活
编辑：其他用户贡献的点：
  • 规模化更难、更昂贵
  • Not strongly-typed.
  • Cannot easily refactor, breaks clients at runtime.
  • Not unit-testable.
  • Most likely not all business logic can be a stored-proc so your logic is split amongst db and code.
  • Stored procedures are not as capable or powerful as a programming language
  • Harder to obtain the right level of encapsulation requiring your client to know the internals of your data schema
  • Harder to version
  • Business logic is tied to a database vendor which you'll be stuck with for life
Edit: other user-contributed points:
  • harder and more expensive to scale
回复 原文
我是有多爱你 2024-08-28 11:14:02

专业的网络服务，反对数据库逻辑：

  1. 如果您的数据库被其他人共享，那么如果您将逻辑放入数据库中，您的应用程序现在将在数据层和逻辑层耦合。这通常是一件坏事。
  2. 我会担心数据库服务器上的负载。如果您的关系数据库受到查询和计算的打击，您将无法像中间层进行计算那样轻松地扩展它。

专业的数据库逻辑，反对网络服务：

  1. 如果数据库完全归您的应用程序所有，也许将逻辑放入其中是一个可以接受的选择。
  2. 我不太担心切换数据库的恐惧，因为这种情况比中间层更改更罕见。中间件时尚来来去去，但数据是任何企业皇冠上的宝石。
  3. Web 服务也有其缺点。将 XML 转换为对象并返回会浪费 CPU 周期。内存中调用比网络调用快几个数量级。如今，到“简单”服务的单次往返可能需要 200 毫秒，但如果开始将这些时间加起来，很快您的 SLA 就会消失。

不要屈服于教条。考虑两者的优缺点，并根据您的应用程序的具体情况做出理性的决定。听起来你和你的同事都做出了非黑即白的情感决定。请记住：结果并不反映你作为一个人。当它投入生产后，你会发现它对你作为设计师的影响。

Pro web services, con database logic:

  1. If your database is shared by others your app will now be coupled both at the data and logical layers if you put the logic in the database. That's usually a bad thing.
  2. I would be concerned about load on the database server. If your relational database is getting hammered by queries and calculations you won't have the possibility to scale it as easily as you would if the middle tier is doing calculations.

Pro database logic, con web services:

  1. If the database is wholly owned by your app, perhaps putting the logic in it is an acceptable choice.
  2. I don't worry as much about the fear of switching databases, because that happens more rarely than middle tier changes. Middleware fashions come and go, but the data is the crown jewel of any business.
  3. Web services have their downside, too. Translating XML to objects and back is a waste of CPU cycles. In-memory calls are orders of magnitude faster than network calls. A single roundtrip to your "simple" service today might be 200 ms, but start adding those up and pretty soon your SLA will be gone.

Don't give in to dogma. Consider the pros and cons of both and make a rational decision based on your app's particular situation. Both you and your co-worker sound like you've make it a black or white emotional decision. Remember: the outcome doesn't reflect on you as a person. You'll find out about what it says about you as a designer after it's in production.

回复 原文
心欲静而疯不止 2024-08-28 11:14:02

定义业务逻辑

无论如何，您只需使用数据库来完成它所要做的事情做得最好。诸如聚合和数据完整性之类的东西。

但每个系统都是一种妥协。如果您有 5 组不同的客户端，那么数据库可能是最好的地方。并非每个电子表格或 Access DB 都可以调用漂亮的中间层 Web 服务...

Define business logic

Anyway, you simply use the DB to do what it does best. Stuff like aggregation and data integrity.

But every system is a compromise. If you have 5 different sets of clients, then the DB might be the best place. Not every spreadsheet or Access DB can call your beautiful middle tier web services...

回复 原文
~没有更多了~

关于作者

爱，才寂寞

暂无简介

0 文章
0 评论
23 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

束缚ｍ

文章 0 评论 0

alipaysp_VP2a8Q4rgx

文章 0 评论 0

α

文章 0 评论 0

一口甜

文章 0 评论 0

厌味

文章 0 评论 0

转身泪倾城

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文