Solution structure vs. architecture

Topics: User Forum
Jul 20, 2007 at 10:44 PM
I'm having a hard time making the connection between the typical 3 layer architecture (which I think WCSF follows) and the way the template & recipes lay the projects out.

I have a large legacy enterprise system (ASP with some ASPX, no architecture at all) that I'm working hard to redesign and rewrite piece by piece, and would really like to conform to the standards and practices, as well as make use of the GAT stuff, the WCSF has. But it's not very clear to me where to try to put stuff. I've been reading the documentation and lots of articles online for WCSF as well as the whole provider model for ASP.NET 2.0. But I feel at a loss as to where to really begin.

I'm in the middle of redesigning our security subsystem as we quite thoroughly failed an audit (hence lots of research on Membership, Roles, etc. in 2.0). So now I have a good understanding of what these providers can do for me and I've started writing some proof-of-concept code. I've got a basic solution skeleton that is pretty similar to my legacy system, and I'm going to roll through the process of enabling WCSF for the solution, but then what? Build a business module for security? Or make use of the Shell module for security? How about data access (everything is database-based for this system)? Where is the whole connection between modules and the recommended way to have them talk to the database? I know the Service Factory has the Data Access Guidance stuff (and the Repository Factory will be out soon) but WSSF doesn't use modules... they more clearly adhere to 3-layer design.

Any help is appreciated.
Jul 24, 2007 at 8:34 PM
Well... not much of a showing.

Let me ask a simpler question and see if anyone has anything they can offer.

When doing data access following WCSF architecture and guidance would you use the service agent pattern? Would you have a common data access project like the WSSF does?

Jul 24, 2007 at 10:13 PM
I don't think the WCSF does or tries to pidgeon hole you into building applications using a particular architecture. You can use the Three-layered service application ( TSLA ) or perhaps use Domain-Driven Design.

The WCSF targets Composite Web Applications. The documentation and RI targets a business module as a Line of Business Application associated with web pages and foundation modules as global services to be used by any business module. That being said, you can see where the community is trying to leverage the WCSF to build portals and non-composite web applications. I think this shows a real need for guidance in these areas as well as the fact that the WCSF helps solve problems comon to general web client development that is not necessarily in the scope of applications that are targeted.

To address your specific questions.

I think the WCSF generated architecture fits nicely with TSLA. The website or WAP is the presentation layer. The business module is the business layer. And, the data access layer can either be a global service ( in foundation module ) or module service ( in business module ).

If you are using the Data Access Guidance Package in the WSSF, the beauty is that you can assign roles to particular projects. I talk about that here:

Enable Data Access Guidance Package in Web Client Software Factory Solution - Code Generation

So, you have the freedom of choosing your repository classes to be defined in a business module or a foundation module dependending on whether you want to scope the data access at the business module ( local ) level or foundation module ( global ) level.

Cross-cutting concerns like security, validation, logging, exception handling, etc. are typically global services and probably meant for a foundation module. The Shell Module is a foundation module so you could define security services in the Shell Module. However, chances are you would be better off defining it in a separate module where it is more pluggable. You can certainly register your services in the Shell Module, but put the implementation in separate modules.

Personally, I break my applications up much more than the WCSF. I typically have separate projects for presenters, the UI model, an application or service layer, etc. In the next version of WCSF, 2.0, you are going to see a lot more guidance for using the WCSF in existing ASP.NET applications and for applications using your architectural preferences.




David Hayden
Microsoft MVP C#
Jul 25, 2007 at 9:27 PM
Edited Jul 25, 2007 at 9:29 PM
Thanks for your response David. I've watched your screencasts and read your blog and it's cool to see someone put so much energy into a community like this.

The thing that brought me to the WCSF was an effort to find architectural guidance for building enterprise web applications. I've inherited a mess of a system, and my whole division is full of similar messy systems written by the same group of hack developers; and there is no architectural guidance, no guru developers, no exemplary software anywhere here to be able to go to for advice, or examples. I had a very good experience with a member of the MS P&P team at Tech Ed 2005 (when I was working for a different company) so I was very excited to see this offering from P&P.

But I've had a very hard time trying to glean the architectural guidance from WCSF. They explain individual pieces well enough (I love the idea of view/presenter), but they never really take a step back and try to tie things together. I guess they assume people have prior knowledge, or can go find that information somewhere else, or are just able to see how typical three-layer design can be done with WCSF's project structure.

The thing there is, the structure of your solutions and projects is really dictated by your chosen architecture (or vice versa), and when you proscribe a radical setup like WCSF does, with so many projects, and no clear layering (other than UI/not-UI) at a high level then I, for one, get lost. It has taken me quite a while to finally put the pieces together in my head and understand what they're doing here. With the last piece I was missing being how data access is supposed to fit in (the reference implementation notably has none... /sigh). It is especially confusing when the WSSF so clearly lays the projects out in typical three-layer fashion. There seems a large disconnect between the different software factories that I hope the P&P leads will try to reconcile.

I do feel I have a handle on it now, especially with your response. The key for me is understanding the way WCSF takes a typical three-layer design and slices it up vertically to define modules. Modules are a very nice way to divide the system up functionally and for independent deployment. But it took finally understanding that most of the time each module "slice" encompasses all three layers, and your module's folder will have a BL project, an entity project (as needed), and then whatever projects you need for resource access (service proxies, agents, data access). Or you can move some resource access to a global foundational module, as you mentioned.

I finally have some time to start building some proof-of-concept setups, so being able to do it will help cement things in my mind.
Jul 26, 2007 at 3:00 AM
You got it right slider, the modules are meant to be sliced on business concepts. Each module is built following a layered approach.

This approach is not opposite to the WSSF approach. My personal take on the WSSF is that modules are meant to be the service itself, which is displayed on its reference implementation.