CODEWITHSUNDEEP
c#
Oleg Vazhnev
Oleg Vazhnev

Reputation: 24067

how to separate several "a little bit connected" projects?

The main class in my program is OrderBook of some stock.

All parts of my program share the same instances of OrderBook. But parts itself are pretty independent. For example I can just run NYSE Connector without running anything else. Then I will just collect OrderBook. Doesn't make much sense, but possible.

Also I need everything to work asap, because even 1 ms is very important for me.

So now I just placed everything in one project (but in different folders), but I think it is not very good. If I will need another connector - I will just create one another folder.

How can I better separate my parts? But remember I need to share the same OrderBook instances.

Upvotes: 0

Views: 124

Answers (1)

Chris Shain
Chris Shain

Reputation: 51329

This is going to be a vague answer, because this is a vague question. Based off of your name (javapowered), I am going to assume that you are coming from a java background and as such I'll try to couch my answer in terms of java equivalence.

In .NET your unit of compiled code is an assembly. The output of each project in a solution is usually exactly one assembly (not always, but for the purposes of discussion lets say it is just one). Assemblies are roughly analogous to Java jar files, in that they contain the bytecode for compiled classes. They are actually significantly more sophisticated than jar files, but that's more or less irrelevant to this answer.

Assemblies can contain references to (read: dependencies on) other assemblies. Unlike the implicit class-by-class dependencies in java, .NET assembly dependencies are explicit and at the assembly level, e.g. assembly foo.bar depends on assembly foo.bat. .NET assembly references must be a directed acyclic graph, meaning that you cannot have any loops where assembly A depends on B which in turn depends on A. The runtime must be able to load all of an assembly's dependencies.

In your case, what I'd expect to see is 4 or more projects:

  1. A main project. Probably your executable. This would have references to (depend on) all of the other projects.
  2. A library project. This would have no references to other projects within the solution.
  3. A connector project for NYSE, referencing the library project.
  4. A connector project for LSE, referencing the library project.

All of the classes that were common to all of the projects (OrderBook, other data structures, etc) would go in Library, where they can be references from anywhere that they are needed.

All of the exchange-specific implementations would go in their own exchange-specific assemblies. This might include protocol handlers that are exchange-specific, subclasses of OrderBook, whatever. If it is specific to an exchange, it goes in 3 or 4 above.

Finally all user interaction logic, control flow, etc would go in the main executable.

Upvotes: 2

Related Questions