模块化系统架构
我正在尝试在我的 POS 系统中实现模块化，以允许第三方执行某种模块/插件/附加组件。我已经开始实现 SPI 和 API，我的问题是：对数据库数据的访问必须通过这种方式，或者我需要提供服务？
此时您可能已经注意到我在这方面的经验很少，因此本主题中的任何建议都很好
编辑：更多信息。我的系统有一个用户系统，理论上检查访问系统任何部分的凭据，mysql数据库是用Java编写的。我的模块需要安全地访问数据库中的某些表，访问主菜单，我不知道还能说什么，但我的问题更多的是抽象地讲 api 需要如何。
提前致谢
PS 抱歉，如果我的英语不好
奥克塔维奥·鲁伊斯
I'm trying to implement modularity in my POS system to allow 3rd parties to do some kind of modules/plugins/add ons. I have started implementing a SPI and an API, my question is: the access to the data on database has to be by this way or I need to provide a Service?
At this point you may have noticed that I have few experience in this, so any advice in this topic is well
Edit: A little more information. My system has an user's system theorically checking credentials to access any part of the system, mysql database, is written in Java. My modules securely need access to some tables in the DB, access to main menu, I don't know what else I can say, but my question is more about abstractedly how an api need be.
thanks in advance
PS Sorry if my english is bad
Octavio Ruiz
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，软件系统（通常）被分为“层”（例如用户界面（UI）、业务逻辑（BL）、数据访问层（DAL）等）。这些层还提供了自然的整合场所。所以...
根据您的说法，我认为其他系统应该通过服务或 API 进行集成。提供对数据库的直接访问意味着他们将回避应该应用于他们想要执行的交互的业务逻辑。在您的具体情况下，这也可能意味着他们会回避您的安全措施。
模块化
这有两个部分：
设计模式
Wikipedia 是一个介绍模式的好地方，StackOverflow 也有很多关于模式的精彩内容。
我开始了解所谓的 SOLID，尽管这就是全部有用 我认为您会发现 S、O、I 和 D 区域最有价值。
就模块化而言，依赖倒置（“D”）将与您特别相关。通过接口创建“合同”，您可以创建其他各方可以构建的东西 - 例如：他们可以用他们所做的实现替换您的“默认”实现。
特定于技术
我无法专门针对 Java 进行讨论（尽管您应该很容易找出答案），但是 .Net 有一些专门为此类事情构建的框架，例如： 托管扩展性框架（MEF）。
关键是大多数技术堆栈将提供用于构建模块化系统的各种框架、工具和方法。
In general terms, software systems are (usually) broken up into "layers" (such as the User Interface (UI), Business Logic (BL), Data Access Layer (DAL) and so on). These layers also provide natural places to integrate with. So...
From what you've said I would think other systems should integrate via a service, or API. Giving direct access to the database means that they'll side-step the Business Logic that should apply to the interactions they want to perform. In your specific case it will probably also mean they'll side-step your security measures.
Modularity
There is two parts to this:
Design Patterns
Wikipedia is a great place to get an introduction into patterns, and StackOverflow has lots of great content around them too.
I's start off getitng to grips with what's known as SOLID, although it's all useful I think you'll find the S, O, I and D areas of most value.
Dependency Inversion (the "D") is going to be particularly relevant to you as far as modularity goes. By creating a "contract" via an interface, you create something that other parties can build on - for example: they can swap out your "default" implementation with one they have made.
Technology Specific
I can't speak specifically for Java (although it should be easy for you to find out) but .Net has a few frameworks that are specifically built for this kind of thing, e.g: the Managed Extensibility Framework (MEF).
The point is that most technology stacks will offer various frameworks, tools and approaches for building modular systems.