I did check before posting so if this is a dup I apologize.
I am working on what will start as a WinForms application that is a layered design based on the MVP pattern. I have created two assembly projects that will start as my presentation layer.
Company.Project.Presentation.Core -- This assembly contains all contracts/interfaces for views and presenters
Company.Project.Presentation.WinForms -- This assembly contains the concrete implementations of the views and presenters.
The main reason I thought to do this was so that if we decided to move to WPF then the contracts would be in their own independent assembly.
Does this seem like a good idea? or am I just increasing the number of projects in my solution when one assembly with sub-folders/namespaces would be good enough?
Thanks for any input in advance,
Jeremie
It is generally a good idea to separate your business logic and implementation details from your UI. A separate assembly is a common and visible way to enforce this. Also, making the assembly name match the namespace name is a great idea.
So far so good :)
I would do more than just put contracts in it, though. I'd place all the core business logic in it as well, separating it from the UI as much as possible.
am I just increasing the number of projects in my solution when one assembly with sub-folders/namespaces would be good enough?
If you have a potential for multiple programs to reuse that logic, you absolutely should keep it in a separate assembly. Exposing the logic through a console application (for scriptability) or a web application are common refactors in many companies.
I'd personally determine the likelyhood of those things for my project/company before I worried about those possibilities very much. But I'd still separate my business logic as it would save me time later, because it always lowers the barrier to maintenance work (bug fixes, etc).
Multiple projects can easily be browsed if you're using your Visual Studio shortcuts correctly. F12 is a good one to learn, as it will take you straight to the code that implements what your cursor is focused on.