业务对象又从何入手？
我正在创建一个新数据库并将旧数据移入其中。我想为新系统创建业务对象并查看旧系统，看起来这些对象基于旧数据库中的表。这是创建业务对象的正确方法吗？
I am in the process of creating a new database and moving old data into it. I would like to create Business Objects for the new system and looking at the old system, it looks like the objects are based on the tables in the old database. Is this the correct way to create business objects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正确规范化的数据库与正确的面向对象设计完全不同。数据库的需求与软件应用程序的需求非常不同。
您应该根据应用程序的使用方式要求来设计您的应用程序。应用程序应该执行哪些操作？需要哪些对象来支持这些需求？他们之间有什么天然的关系？
单个业务对象可以存储在十几个数据库表中，或者单个表可以存储十几个对象的数据。这实际上取决于您正在使用的系统的具体情况。
A properly normalized database will look nothing like a proper object-oriented design. The needs of a database are very different from the needs of a software application.
You should design your application according to the requirements for how it is to be used. What sorts of things is the application supposed to do? What objects will be required to support those needs? And what are the natural relationships between them?
A single business object may be stored across a dozen database tables, or a single table may store data for a dozen objects. It really depends on the specifics of the system you are working with.
如果旧数据库被正确规范化，您会发现许多表确实对应于业务对象。但是...
您对业务对象的构成的决定不应仅限于此。你需要研究场景并决定业务对什么感兴趣。你对业务的理解将是主要决定因素。
If the old database was properly normalized you will find that many tables do correspond to business objects. However...
Your decision about what constitutes a business object should not be restricted to that. You need to study the scenario and decide what the business is interested in. You understanding of the business will be the main determinator.
这里没有太多细节，但有一个建议......
从新系统必须做的“什么”开始。 [新]系统应该支持哪些[新]功能。需要什么数据。您的新系统很可能应该满足新的要求或以不同和/或更好的方式满足新的要求。
在您对事物和需求有了相当清晰的了解之后，请跟进“如何”；如何解决这些“是什么”。做一些业务对象建模。
在业务对象建模之后，您可以开始讨论另一个“如何”，即数据库设计。然后就可以做数据迁移的事情了。
遵循这一点并不意味着完全忘记旧的系统/数据库。如果您认为可以从旧方法中获得任何好的或有价值的东西，请接受它并尝试尽可能地将其合并/整合到新方法中。
Without much details here is one suggestion...
Start with the "what" the new system has to do. What [new] functions should the [new] system support. What data is required. Very likely your new system should address new requirements or address new requirements in a different and/or better way.
After you have a fairly clear picture of things and requirement needs, follow up with the "how"; how to address those "whats". Do some business objects modeling.
After the business objects modeling you can get down to another "how", the database design. Then you can do the data migration thing.
Following this does not mean completely forgetting about the old system/database. If there's anything good or valuable you think you can take from the old ways, take it and try to incorporate/integrate that into the new ways as best as you can.