经理班？
我正在编写一个 .net webforms 应用程序。 它有很多类，例如用户、预订等。 目前，我有许多管理类，例如 bookingManager，用于管理这些类。 例如，当创建一个新的预订时，您可以调用 bookingManager 中的 add 方法，并传递一个预订。 然后它检查预订是否有效，检查是否不冲突，如果不冲突，则将其添加到数据库中。 我对其他类有类似的管理器，但是诸如用户管理器之类的管理器除了获取用户并将其添加到数据库之外并没有做更多的事情。 所以我的问题是，这是做这类事情的最佳方式，还是有更适合于此的模式或方法？
Im writing a .net webforms app. It has a number of classes, for example users, bookings etc.
At the moment I have a number of manager classes, say bookingManager, that manage these classes. For example when creating a new booking, you call the add method in the bookingManager, and pass a booking. It then checks the booking is valid, checkis it doesn't conflict, and if it does not, adds it to the db.
I have similar managers for the other classes, however ones such as the user manager don't do alot more than take the user and add to the DB.
So my question is, is this the best way to be doing this sort of thing, or is there a pattern or method thats better suited to this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正如您所描述的，您已经在使用一种模式，即 3 层模式:)
这表明在应用程序中您应该将代码分为 3 层（如名称所示）：
表示层：您将代码写入的位置呈现您的数据 (ASPx/winforms/etc)
应用程序层：您放置所有业务逻辑的位置（您的业务逻辑）
当您有一个具有多个地址的客户端（客户端存储在一个表中而地址存储在另一个表中）时，遵循此模式可能会很有用。 在表示层中，您只需调用应用程序层中的方法来保存客户端。 在应用程序层中，您将检查数据并调用数据层中的两种方法，一种用于保存客户端，一种用于保存地址。
现在，如果您的供应商具有多个地址，您可以在数据层中使用相同的方法来保存它们。
如果您有复杂的对象，这将很有用。 但是，如果您的大多数对象都很简单，我建议您仔细考虑一下这种模式是否适合您。
http://en.wikipedia.org/wiki/Multitier_architecture
as you describe it you are already using a pattern, the 3 Tier pattern :)
This states that in the application you should have your code into 3 tiers (as the name states):
Presentation Tier : Where you write the code to present your data (ASPx/winforms/etc)
Application Tier : where you place all your business logic (what you are doing with the Manager Classes)
Data Tier : Where you do the actual access to the database.
Following this pattern can be useful when, you have something like a client with multiple addresses the client is stored in one table and the addresses in another. In your presentation tier you just invoke a method in the application tier to save the client. In the application tier you will check your data and invoke two methods in the Data tier, one for saving the client one for saving the addresses.
Now if you have suppliers with multiple addresses you can use the same method in the Data tier to save them.
This will be useful if you have complex objects. however if most of your objects are just plain simple I would recommend that you think it over if this pattern is the right one for you.
http://en.wikipedia.org/wiki/Multitier_architecture
如果管理器就像 UI 和域类之间的控制器/演示者，我认为它应该是薄层。 它应该包含几行代码。 然后领域服务或服务类应该负责剩下的工作。 例如：
UI:
Presneter:
Service ：
对于小型应用程序来说它可能有点过大，但对于大型应用程序来说它提高了可维护性。 您可以查看领域驱动设计书籍和领域服务课程。
If manager is like a controller/Presenter between UI and Domain Classes I think it should be thin layer. It should contains a few lines of code. Then Domain Services or Service classes should take care of rest job. For example :
UI:
Presneter:
Service :
it can be overkill for small applications but for a big application it increases maintainablitiy. You can look at Domain Driven Design book and Domain Service classes.
拥有经理类并没有什么问题，特别是当他们管理系统的几个不同方面时，例如您提到的预订经理。 在这种情况下，您可能不希望用户了解预订，或预订了解用户 - 但这自然取决于您系统的具体情况。
管理器的好处在于，它提供了一个集中且逻辑的位置来存储可能依赖于多个组件的复杂逻辑。 它还允许您像这样使用数据类，并增加这些类的内聚力。
关于管理器的“不太好的”事情是，您有另一个组件，它可能会与系统中的其他组件紧密耦合。 您需要平衡其优点和缺点，并选择对您的应用程序最有意义的架构。
There is nothing wrong with having manager classes, especially when they manage several different aspects of the system, such as the booking manager you mention. In that case you may not want the user to know about bookings, or bookings to know about users - but this will naturally depend on the specifics of your system.
The nice thing about managers is that it provides a central and logical place to store perhaps complicated logic which depends on multiple components. It also lets you use the data-classes as that and increase the cohesion of those classes.
The "less nice" thing about managers is that you have another component which will likely be reasonably tightly coupled to the other components in the system. You need to balance the pro's and cons of this and go for the architecture that makes the most sense for your application.
我认为为此类类实现保存、删除和更新方法总是更好。 对于此类事情来说 Manager 类绝对是大材小用。 比如说，在 Booking 类中实现的那些方法可以执行相同的验证，并避免因在代码中添加太多类而引入的任何复杂情况。
I think it is always better to implement a Save, Delete and Update method for such classes. A Manager class for such things is definitely overkill. Those methods implemented in your, say, Booking class could do the same validation and avoid any complications introduced by adding too many classes to your code.