如何开始企业应用程序的类设计？
在开始开发大型应用程序（WinForm 和 WebApp）之前，我如何开始类设计。在设计类结构之前我应该检查哪些最初的“小心”事项？
如何识别应用程序设计中接口、抽象类、委托、事件等的使用？
How can i start with the class design before starting the development of a large application (both WinForm and WebApp). What are the initial 'be-careful' things i should check before designing the class structures?
How to identify the usage of interfaces, abstract classes, delegates, events etc in my application design?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
要彻底回答这个问题需要一本书，而不是 StackOverflow 的帖子！事实上，已经有很多关于这方面的书籍了，比如 Martin Fowler 的 Patterns企业应用架构。以下是一些一般性提示：
确保您了解您正在处理的问题域的部分。您是否曾与您的客户交谈并让他们先处理事情？您的领域模型是否符合他们对世界的看法？
从统计上来说，您的应用程序不太可能很特别。这意味着，如果有人坚持认为他们需要特定的架构或实现模式才能工作（例如企业服务总线、消息队列等），您应该以怀疑的眼光看待它。考虑另一种方法是否可能不是更好。
在结构和逻辑上将应用程序的不相关部分相互隔离。不要只是松散地耦合或解耦你的类；使它们完全独立，必须单独构建。
针对接口的代码，而不是实现。如果许多类都做类似的事情，则创建一个接口。不要使用抽象基类作为伪接口。依赖于接口并传递它，而不是单独的实现类。
了解更大的应用范围。它有什么商业目的？它将如何帮助人们、实现目标或提高生产力？您正在构建的东西是否与该目的一致？确保您不是为了构建而构建。
当有人告诉您这是“企业应用程序”时，请保持警惕。对于太多不同的人来说，这是一个含义丰富的术语。确保清楚安全、授权、身份验证、服务保证等跨领域问题。
企业应用程序很容易膨胀。不要害怕对新功能说“不”，并通过良好的单元测试进行无情的重构，以确保您获得最大的收益。
最后，一切都要适度。将上述任何一项（或任何一般情况，实际上）走向极端都是一个坏主意。在极端情况下，你真正应该做的唯一一件事就是节制本身！ :)
A thorough answer to this question would require a book, not a StackOverflow post! In fact, there are quite a few books about this already, like Martin Fowler's Patterns of Enterprise Application Architecture. Here are some general pointers:
Make sure you understand the portion of the problem domain that you're working on. Have you talked to your customers to run things by them first? Does your domain model match the way they think about the world?
Statistically speaking, your application is unlikely to be special. That means that if someone insists that they need a particular architecture or implementation pattern for things to work (e.g. an enterprise service bus, message queues, etc.), you should view it with a skeptical eye. Consider whether another approach might not be better.
Isolate unrelated portions of the application from each other structurally as well as logically. Don't just loosely couple or decouple your classes; make them entirely separate projects that must be built separately.
Code to interface, not implementation. If a number of classes all do something similar, make an interface. Don't use abstract base classes as pseudo-interfaces. Depend on the interface and pass that around instead of the individual implementing classes.
Understand the larger scope of the application. What business purpose does it serve? How will it help people, accomplish goals, or improve productivity? Are the things that you're building aligned with that purpose? Make sure you're not building for the sake of building.
Be wary when someone tells you that this is an "enterprise application". This is a loaded term with too many connotations for too many different people. Make sure to be clear about cross-cutting concerns like security, authorization, authentication, service guarantees, et cetera.
Enterprise applications are prone to bloat. Don't be afraid to say "no" to new features, and refactor mercilessly with good unit tests to make sure you're getting the most bang for your buck.
Finally, everything in moderation. Taking any of the above (or anything in general, really) to an extreme is a bad idea. The only thing you should really do in the extreme is moderation itself! :)
为了给你一个大问题的简短答案 - 不要首先从类设计开始。从组件、层的设计开始，并做出一些技术决策，例如“我是否需要数据库，如果需要，是哪个”。这假设您已经对问题域进行了部分分析，找到了一些基本用例等。
当您准备好时，编写一个“直通”应用程序来验证您的架构决策可能是一个好主意。这意味着，一个小型应用程序可以触及大部分层，同时仅处理非常小的用例。它应该足够小，以便当您认为架构的某些部分有缺陷时可以轻松重写/更正/丢弃。这也是初步掌握类设计的好方法。
To give you a short answer to a big question - don't start with the class design first. Start with the design of components, layers, and make some technology decisions like "do I need a database, and if so, which one". This assumes you have already done some portion of analysis of your problem domain, found some essential use cases etc.
When you are ready with that, it may be a good idea to code a "cut-through" application to verify your architectural decisions. That means, a small application that touches most of your layers while handling only a very small use case. It should be small enough to be easily rewritten/corrected/thrown away when you think parts of your architecture are flawed. That's also a good technique to get a first grip on your class design.
我看到两种基本的设计活动。
主要系统部分存在分解。因此，您已经了解了将演示部分与系统的其余部分分开的一些想法。您可能还会有一些业务逻辑和持久性。第一个重要的问题是，您真正拥有多少业务逻辑。有些系统只不过是简单数据库前面的一层薄皮，几乎没有任何真正的业务逻辑。其他人则拥有非常重要的业务逻辑部分，这些部分在某种程度上是独立的。
如果您有主要的半独立部分，它们可能最好通过事件和消息队列进行通信。因此，请确定您是否有需要这种解耦关系的部分，这会导致识别事件和这些事件的有效负载。这是另一个答案中引用的福勒变得相关的地方。
接下来深入研究业务逻辑部分。接口和抽象类等是构建复杂性实现的技术。分离您的代码，以便隐藏细节并实现灵活性。我认为这是一个面向对象的设计练习，有很多关于这方面的书籍，例如 head first 。
I see two fundamental kinds of design activities.
There is a decomposition in primary system pieces. So you've already got some idea of a separation of the presention pieces from the rest of your system. You'll probably have some Business Logic and Persistence too. First important question, how much Business Logic do you really have. Some systems are little more than a thin skin in front of a simple database, hardly any true business logic. Others have very major pieces of Business Logic that are to some extent independent.
If you have major semi-independent pieces they might best communicate via events and message queues. So indentify whether you have pieces that need that kind of decoupled relationship, and that leads to identifying the events and the payloads of those events. Here's where the Fowler referenced in another answer becomes relevent.
Next drill into the Business Logic pieces. Interfaces and Abstract Classes etc. are techniques for structuring the implementation of complexity. Separate your code so that details are hidden and flexibility is enabled. I see this as being an OO design exercise, there are plenty of books about that, for example head first.