如何删除子系统之间的耦合？ [英] how could remove coupling between subsystems?

问题描述

我们公司的
我们有一个框架应用程序，其中包含基本信息和配置数据。公司的其他项目沿着这个框架工作并使用它的数据。例如访问数据，用户信息，菜单或工具栏配置，用户自定义等。

in our company we have a framework application that contain basic information and configuration data .other project of company work along this framework and use its data.for example access data,user information,menus or toolbar configurations,user Customisation,etc.

我们的问题是当框架项目f发生变化时或者示例" S tored
P rocedure"返回用户的访问信息，所有"子系统应用程序"都返回给用户。使用框架必须改变。如果我不想改变
SP  并写一个知道的，我的框架将成为很大，我无法管理SP，最后是错误。你的想法是什么？

our problem is when something change in framework project for example a "Stored Procedure" that return access information for a user,all the "subsystem applications" that use framework have to change.or if I don't want to change the SP and write a knew one,my framework will become large and I couldn't manage SP and finally bugs.what is your idea?

如何在"子系统应用程序"之间删除这种类型的依赖关系。和框架？或者如何管理它们巫婆不需要改变所有

"子系统应用程序"  用于框架的更改？谢谢。

how could remove this type of dependency between "subsystem applications" and framework? or how to manage them witch dont need to change all of "subsystem applications" for a change in framework? thanks.

B.Ghadami

B.Ghadami

推荐答案

我认为你在谈论耦合而不是凝聚力？这是一个很大的话题，应该从你的设计开始，以帮助降低耦合。您可以查看ORM等工具，以帮助解决那里的具体问题，但实际上您需要认真考虑设计中的
。

I think you're talking about Coupling rather than Cohesion? It's a big topic and should start with your design to help lower coupling. You could look at tools such as ORMs that help with the specific issues there but really you want to take a serious look at the design.

http://www.bing.com / search？q = patterns + to + reduce + coupling& src = ie9tr

对我来说，我喜欢走SOA路线，但我认为这只会让事情变得混乱，但如果你对领域驱动设计，Greg Young，Udi Dahan等有所改变，

For me I like to go the SOA route but I think that will just confuse things but if you have a change look for Domain Driven Design, Greg Young, Udi Dahan, etc.

这篇关于如何删除子系统之间的耦合？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！