寻求有关构建 ac# dll 的高级指导
一个小项目为我提供了一个提高自己作为程序员的机会。我可以找到大量描述控制流构造和 dotnet 库的资源，但我没有得到的是如何构建整体代码。我还没有参加过任何形式的结构化编程课程，所以我想确保我不会因为我的理解有限而养成坏习惯。我之前已经完成了大量的过程编程和 GUI 工作。我已经弄清楚了算法和方法。我需要一个关于如何设计这段代码的简短叙述性描述。
具体来说，我想创建一个 dll，其中包含将长格式文本字符串解析为某种结构化数据的代码。我已经准备好必要的正则表达式配方来检索数据。大多数字段都是单一值，但也可能是一对多关系。我应该有多少个班级以及他们的角色是什么？实际解析在哪里发生以及我应该返回什么类型的对象？
在我知道我所描述的模式是什么之前，我不知道如何继续。
A small project has provided me an opportunity to better myself as a programmer. I can find plenty of resources describing control-flow constructs and the dotnet libraries but what I'm not getting is how to structure the code overall. I have have not been through any sort of structured programming curriculum, so I want to make sure I'm not developing bad habits due to my limited understanding. I have done quite a bit of procedural programming and a bit of GUI work previously. I have the algorithms and methodology figured out already. I need a brief narrative description of how to design this code.
Specifically, I want to create a dll that contains code to parse a long formatted-text string into structured data of some sort. I have the necessary Regular Expression recipes prepared to retrieve the data already. Most of the fields will be single values, but one can potentially be a one-to-many relationship. How many classes should I have and what are their roles? Where does the actual parsing happen and what sort of object should I be returning?
I am at a loss regarding how to proceed until I know what sort of pattern that I am describing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先想到3层的应用程序。首先是数据或持久层，这可以是数据库、xml 文件或任何其他数据输入/输出。第二个是领域或业务层，这是实际逻辑和业务层。应用商业活动。最后是表示层，这可以是 Windows 应用程序、网站等。
首先决定是要采用以数据为中心的方法还是以领域为中心的方法。以数据为中心的方法是您的域层类与您的数据结构紧密匹配，使持久性更容易，但表示层更复杂。以领域为中心的方法是您的领域层类更多地反映问题的逻辑实体，通常使表示更加简单，但数据持久性变得复杂。
尝试使每一层尽可能与其他层分开。在需要相互通信的地方使用松散耦合的接口。例如，领域层可以定义一组接口（或契约），准确定义它需要/期望从领域层得到什么（例如，使用存储库模式和 DTO 模式的组合）。类似地，表示层应该为它需要/期望从域层得到的内容定义一个契约，MVVM 模式的 VM 部分就是一个很好的例子。
领域层通常充当数据层和表示层之间的中介，在每层表示业务数据的独特方式之间进行映射。表示层在任何时候都不应该知道数据层，反之亦然。
First think of the application in 3 layers. First is the data or persistance layer, this could be a database, xml files or any other data input/output. The second is the domain or business layer, this is where the actual logic & business activities are applied. Finally is the presentation layer, this could be a windows application, website etc..
First decide if you want to go with a data-centic approach or a domain-centric approach. A data centric approach is where your domain layer classes closely match your data structure, making persistance easier but your presentation layer more complex. A domain centric approach is where your domain layer classes reflect more the logical entities of the problem, often making presentation more straightforward but data persistance complex.
Try and keep each layer seperate from the others as much as possible. Use loosely coupled interfaces where communication between them is required. For example, the domain layer could define a set of interfaces (or contracts) defining exactly what it needs/expects to get out of the domain layer (using a combination of the repository pattern and DTO pattern, for example). Similarly, the presentation layer should define a contract for exactly what it needs/expects to get out of the domain layer, the VM part of the MVVM pattern is a good example of this.
The domain layer often acts as a mediary between the data and presentation layers, mapping between the unique way that each layer represents business data. At no point should the presentation layer be aware of the data layer, or vice versa.
如果您不确定如何构建对象，请查看
OOP SOLID 原则
这是基础中的基础。
就个人而言，任何需要解析/多个参数的实例化，我更喜欢在工厂类中完成它们。这样更容易进行依赖注入。
但老实说，如果您想成为一名出色的程序员，请准备好一次又一次重写。这就是每个人学习的方式:)。
无论你做什么，都不要碰静态方法。他们是邪恶的。
If you are not sure how to structure your objects, take a look at
OOP SOLID Principles
That is the basic of the basics.
Personally, any kind of instantiation that requires parsing/multiple parameters, I prefer to do them in a factory class. Easier to do dependency injection that way.
Honestly though, be prepared to rewrite again and again if you wish to aspire to a great programmer. That's how everyone learns :).
What ever you do, don't touch static methods. They are evil.