I'm looking at the ProjectTracker CSLA example solution and it has projects for DAL, EF implementation of DAL, and a project for the business objects/rules/etc.
I understand it's good practice to split logical separations in to projects, buy my concern is is there really a problem putting the DAL and EF into the business assembly?
It seems that build time is most affected by the number of projects.
The app I'm working on would likely have 18 or more projects if i followed the examples layout.
I know i can make multiple solutions to help mitigate this, but I don't want to go down this path right off the start.
Thanks.
Multiple projects are recommended, and are necessary to get the full benefit of CSLA and its n-tier architecture.
If you know beyond the shadow of any doubt that you will never need n-tier deployment, never need advanced security, never need increased scalability, and generally aren't looking to build an enterprise level app, then you can use fewer projects.
In fact, if you are building an app that you know you'll deploy as a 2-tier app then you can put the business classes and data access classes directly into your UI project along with the UI code.
Is that a good idea? No.
Will it work? Yes.