Seeking high-level guidance on structuring a c# dll

A small project has provided me an opportunity to better myself as a programmer. I开发者_StackOverflow社区 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.

---

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.

---

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.