architecture advice in c#

[Lee]

Hello

I'm after a bit of advice regarding the UI boundary, I've searched around but the information i've found is often clouded with information regarding frameworks, etc which i'm not using and know nothing about.

My scenario is that i want to create an application that will largely be manipulating data in a database, adding and/or removing data etc, the database is actually used by a different application that doesn't have a UI at all.

My current thoughts, using C# and Visual Studio, are to have the following components;

1. a class library that is the core application containing the use cases and abstractions etc.

2. a class library that provides the data repository implementation.

3. a GUI, possibly windows forms, console app, or both.

4. probably a class library that provides the implementation of a use case factory.

Assuming the above, when run the UI would be the program that starts and therefore would create the instance of the repository (in this case sql database) that the use cases would use as the various data gateways, should it be a use case that handles the connecting and opening of the database or should the db be passed into the application ready to use? in a similar manner i'm thinking that 'main' in the UI program would also create the factory instance and likely give the factory the database/gateway instance, using a setter, so the factory can pass the data gateways to the use cases, as an instance of the applicable interface, when the use cases are constructed. 

does this all sound reasonable?

any thoughts appreciated

Lee

[Breno Sarkis]

Hello Lee,

Regarding project design (in a clean architecture fashion), I recommend you watch Episode 18 of cleancoders.com.

I'm not sure I understood you correctly, but anyway, I wouldnt create repository instances in the UI boundary, I'd leave this to a side project, someone that has only this responsability. I'd allow the UI to ask for these things but not create them itself.

Hope this helps.

[unclebob]

Think of "main" as a stand-along program that creates the GUI you need, connects to the database, constructs the factories, and wires the whole operation together.

[Lee]

Hello

Thanks for the replies.

So in essence, in this scenario, I should create a GUI-less application that runs and creates the instances of the repository, core application and GUI component (which would now be a dll with the forms in), etc, and the start up application would then display the main form from the GUI library after wiring everything up.

I suppose this also answers my question regarding whether any processing required to connect to the repository should be a use-case, as information would be required by the user (where/what to connect to, etc), then it must be handled by use cases.

Thanks

Lee