对象映射 - 扁平化为属性而不是对象引用
N_Tier 架构的知识
我正在尝试完善BLL 内部 ，并且如果我在 BLL 中使用自定义业务对象，例如 CustomerInfo {FN，LS，...}，请考虑我有 Customer 表和货币表，Customer 是有默认货币，因此Customer表中有一个FKCurrency_ID，在UI层，我们需要显示货币符号而不是Currency_ID。 （选择...内连接..）
我是否可以将货币符号作为 CustomerInfo 中的属性，而不是在 CustomerInfo 中放置货币信息的引用。
我认为答案是“否”，但为什么呢？什么会变坏？
数据库中的每个业务表（不包括验证查找）是否都应该映射到业务对象？
我认为业务对象（包含从DAL带来的数据的对象）应该仔细映射到数据库中的表，这可以增加可维护性。但 BLL 可以包含用于业务操作和业务验证的任何对象。
请给我一些书名或链接，以掌握 N 层架构及其辩论。
谢谢
I am trying to refine my knowledge of N_Tier arch
Inside the BLL, and In case I am using custom business objects in BLL, like CustomerInfo {FN, LS, ...}, Consider that I have Customer table and Currency table, Customer is having a default currency, thus there is a FK Currency_ID in Customer table, at UI layer, we need to show Currency symbol instead of Currency_ID. (SELECT...INNER JOIN..)
Can I put the Currency symbol as a property in CustomerInfo, instead of putting a reference of CurrencyInfo inside CustomerInfo.
I think No is the answer, but Why? What can go bad?
Should every business table (excluding validation lookups) in database maps to a business object?
I think business objects (objects which contain the data brought form DAL) should be carefully mapped to tables in database, this can increase the maintainability. But BLL can contain any objects for business operations and business validations.
Please give me some books titles, or links to master the N-tier arch and the debates about it.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
也许您应该阅读一些有关设计模式的优秀书籍（有关该主题的维基百科页面链接到其中一些）。特别是，您可能会发现数据传输对象 (DTO) 的概念是一个很好的概念。拥有一个与数据库紧密映射的域模型是很常见的做法，可能使用对象关系映射工具，例如 (N )休眠，iBatis 等等，但是要拥有一组转换器/适配器，将它们转换为稍微扁平化的对象（如您描述的 CustomerInfo 对象），更好地适合我们的应用程序需要显示和显示的方式处理数据。
Perhaps you should read some of the many excellent books on design patterns (the Wikipedia page on the subject links to some of them). In particular, you may find the concept of a data transfer object (DTO) a good one. It is quite common practice to have a domain model that maps closely to your database, possibly using an object-relational mapping tool like (N)Hibernate, iBatis and so on, but to then have a set of converters/adapters that turn these into slightly flatter objects (like the CustomerInfo object you describe) that better fit the way our application needs to display and process the data.
如果您想使用货币符号作为CurrencyInfo 表的自然键，为什么不直接将其设为CurrencyInfo 表中的主键呢？
Joe Celco http://www.celko.com/ 特别提倡这种方法。
Celko on SQL：自然键、人工键和代理键解释
http://intelligent-enterprise.informationweek.com/showArticle。 jhtml;jsessionid=EJ2IXIZ2R4MSLQE1GHOSKH4ATMY32JVN?articleID=201806814
If you want to use a currency symbol as a natural key to the CurrencyInfo table, why not just make it a primary key in CurrencyInfo table?
Joe Celco http://www.celko.com/ especially advocates this approach.
Celko on SQL: Natural, Artificial and Surrogate Keys Explained
http://intelligent-enterprise.informationweek.com/showArticle.jhtml;jsessionid=EJ2IXIZ2R4MSLQE1GHOSKH4ATMY32JVN?articleID=201806814