业务逻辑层设计 [英] Business Logic Layer Design
问题描述
你好，
我觉得这个问题就像这样一个菜鸟，但现在一直困扰着我。
在设计分层应用程序的BLL时，您是否将所有实体类放在一个名称空间中？例如：如果您有一个包含客户及其车辆的数据库，并且这些车辆可以按月计算。我认为可以将客户和他们的车辆保持在与服务模块不同的模块中（因此，如果您需要更新服务的方式或存储数据的位置，那么您可以不需要触摸Customer \Vehicle模块。）
我是这样思考还是应该改变我的设计理念？
这让我遇到了使用LINQ to SQL的问题。如果一半的表''实体类包含在''模块''A中，另一个包含在''模块''B中，那么你将在某个地方拥有''模块''参考''模块''B和副反之亦然，以容纳2个与''模块''边界的桌子之间的关联。
OR（现在只想到这个）你有1个桌子吗？ ''modules''中的实体类重叠（两个模块中有相同的类）？
任何建议都会受到赞赏。
谢谢
你是否还有一个数据访问层是不完全清楚的，因为你提到如果你曾经需要更新服务的完成方式或存储数据的位置，您无需触及Customer \Vehicle模块。 DAL将负责处理检索和存储数据，无论何时可能。
但当然可能必须更新车辆，如果需要在一个地方更新这些规则，那将是最方便的。您可以使用这些规则创建Customer和Vehicle BLL。然后，您只需添加一个使用Customer和Vehicle的CustomerVehicleService。没有规则你不能。
也许这个链接也可以帮到你：
http://msdn.microsoft.com/en-us/library/aa581779.aspx [ ^ ]
祝你好运！
我同意了。
一般来说，每个BLL都在不同的模块上实现。正如你在不同的名称或简单的项目中所说的那样。因此，在以后的情况下您必须做的更改是最小的。然而，这取决于你的接口（意味着每个命名空间上的处理访问器）如何在每个模块上实现它们之间的通信。
我认为那些基于你的架构实现技能和经验。因为你可以在很多方面根据自己的意愿进行自定义。
对于数据库结构，我更喜欢使用相关主键来构建平面结构。然后我也不想担心DBMS的变更。
我会将整个数据库保存在一个模型中，直到有充分的理由不这样做：
KISS [ ^ ]
YAGNI [ ^ ]
Hi there,
I feel like such a noob for asking this question, but it''s been bugging me for a while now.
When designing the BLL of a tiered application, would you put all your entity classes in one namespace? For example: If you have a database with Customers and their Vehicles and these Vehicles get Serviced on lets say a Monthly basis. I would think one would keep the Customers and their Vehicles in a separate ''module'' from the ''services module'' (so that if you ever need to update the way services are done or where the data is stored, you do not need to touch the Customer\Vehicle module).
Am I correct in thinking this way or should I change my design ideas?
This has presented me with a problem with using LINQ to SQL. If half of the tables'' entity classes is contained in ''module'' A and the other in ''module'' B then somewhere you are going to have ''module'' A reference ''module'' B and vice versa to accommodate the associations between 2 tables that border with the ''modules''.
OR (just thought about this now) would you have 1 table''s entity class overlap in the ''modules'' (having the same class in both modules)?
Any advice would be appreciated.
Thanks
It isn''t completely clear if you also have a Data Access Layer because you mention "so that if you ever need to update the way services are done or where the data is stored, you do not need to touch the Customer\Vehicle module". The DAL would take care of handling the retrieving and storing the data, where ever that may be.
But of course it could be that Vehicle must be updated and it would be most convenient if updating those rules needed to be done in one place. You could simply create a Customer and Vehicle BLL with those rules. Then you just add a CustomerVehicleService that uses the Customer and Vehicle. There isn''t a rule you can''t.
Maybe this link could also help you:
http://msdn.microsoft.com/en-us/library/aa581779.aspx[^]
Good luck!
I agreed.
In general each BLL implement on different modules. As you said in different namespases or simply projects. So that the changes you have to do in later cases are minimal. However it depends on how your interface (means the handling accessors on each namespaces) is implemented on each module for communicating between them.
I think those architectural implementation based on your skills and experience. Because you can customize as you wish in many ways.
When comes to the database structures, I prefer to maintin a flat structure with relevant primary keys. Then I don''t want to worry about the DBMS alternations as well.
I would keep the whole database in one model until there is a good reason not to:
KISS[^]
YAGNI[^]
这篇关于业务逻辑层设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
