April 18, 2007
How to Structure .NET Solutions and ComponentsUdi Dahan
A bigger development team shouldn't mean bigger project development headaches. Udi provides guidelines on how to structure a large .NET project to take advantage of SOA principles.
This week's podcast answers some recent questions emailed from a reader:
Hi Udi, I've been programming on the .NET framework for several years now and want to move towards an architecture role. Additionally, I have been reading up on WCF and related .NET 3.0 technologies, but have more questions than answers. 1. Do you have guidelines/best-practices for how to structure a .NET solution and related assemblies? Also, guidelines as to how to factor the various namespaces and what goes where would be helpful. 2. How should components be factored; i.e., one component to an assembly or multiple components to an assembly? I've read several different articles that go back and forth, but never really got a straight answer. 3. How do components relate to services from an SOA perspective? 4. Does application scope/size impact the decision to use SOA? And, 5. Do you have any resources that I could use to learn more about SOA and .NET? I appreciate the help and any answers that you can provide. Mike Additional References: On the importance of splitting up projects and DLLs Inversion of Control Containers and the Dependency Injection pattern Dependency Injection Tools: [.NET] Spring Framework [.NET] StructureMap [Java] Spring Framework Podcasts Podcast on Autonomous Services and Pub/Sub Podcast on Business and Autonomous Components in SOA
|
 |
|
|||||||||||||||||||||||||||
|
|
|
