This post has been imported from my previous blog. I did my best to parse XML properly, but it might have some errors.
If you find one, send a Pull Request.
Currently, I’m working with some pieces of a legacy code. There are good old-fashioned DAL, BLL layers which reside in separate projects. Additionally, there is a commo**n project with all the interfaces one could need elsewhere. The whole solution is deployed as one solid piece, without any of the projects used anywhere else. What is your opinion about this structure?
To my mind, splitting one solid piece into non-functional projects is not the best option you can get. Another approach which fits this scenario is using feature orientation and one project in solution to rule them all. An old, the deeper you get in namespace, the more internal you become, is the way to approach feature cross-referencing. So how would one could design a project:
Admin.cs (en tity)
I see the following advantages:
To sum up, you could deal with features oriented toward business or layers oriented toward programming layers. What would you choose?
Are you treating namespaces = folders? Because the way you organize files doesn't necessarily need to match the namespace structureby danielmarbach at 2015-04-09 10:16:13 +0000
Not necessarily. Using R# you can have folders providing no namespaces.by scooletz at 2015-04-09 11:01:23 +0000