Structuring a winforms C# solution

Question

So i am reorganizing a winforms C# solution to help decouple and make it cleaner and more organized. The solution tracks a small business orders,etc . .

I have broken out the projects so far into

App.View - all GUI Related Code
App.Data - just data structures and interfaces. No other implementation code
App.BusinessLogic - all business logic code that has no GUI references

I have some classes that i can't figure out where they belong. Please let me know your thoughts which project each class should go or if there is another project that should get created for this.

1. A Class that retrieves user preferences from a database
2. A Class that retrieves static data from our static data server and returns sets of data results.
3. A Class that brings down user entitlements
4. A model class that stores a hashtable of orders
5. A class that emails out messages on a user action

Answer 1

Actually, I think you have things a little off from a traditional layered architecture. Normally, the models of your data that your application works on would be kept in a business layer, along with the code to operate on them. Your data layer would have both the data models of your persistence framework and the code to interact with that framework. I think this might be the source of the confusion between the suggested locations of your classes and your reaction to it based on your comments.

From that perspective anything that retrieves or brings would necessarily be located in your data layer -- it's accessing data in persistent storage. What it retrieves are eventually converted into business layer objects that your business logic operates on. Things are are conceptual models -- like a table of orders -- or business actions belong in the business layer. I would agree with @Adron with, perhaps, the same confusion about where (3) goes depending on what it actually is.

More specifically:

1. User Preferences are business objects, the thing that retrieves them is a data layer object.
2. The static data maps on to a business object (table or view or something), the thing that accesses the external server is a data layer object.
3. The user entitlement is a business object, the thing that retrieves it is data layer object.
4. A table of Orders is a business object
5. Emailing is a business activity, so the thing that mails people is a business object

[EDIT] My generalized 3-Tier Architecture for (simple) web apps

DataAccessLayer

This would include my TableAdapters and strongly typed DataTables and Factories that turn rows of my DataTables into business objects in pre-LINQ projects. Using LINQ this would include my DataContext and designer generated LINQ entities.

BusinessLayer

This would include any business logic, including validation and security. In pre-LINQ these would be my business objects and any other classes that implement the logic of the application. Using LINQ these are the partial class implementations of my LINQ entities to implement security and validation along with any other classes to implement business logic.

Presentation

These are my web forms -- basically the UI of the app. I do include some of the validation logic in the forms as an optimization, although these are also validated in the BL. This would also include any user controls.

Note: This is the logical structure. The project structure generally mirrors this, but there are some cases, like connections to web services, that may be directly included in the web project even though logically the components are really in the BL/DAL.

Note: I'll probably be moving to MVC over 3-Tier once ASP.NET MVC is in production. I've done some personal projects in Ruby/Rails and I really like the MVC paradigm for web apps.

Answer 2

You have specified that App.Data should contain only data structures and interfaces, no implementation code, which is fine if you want to do that, but that leaves you with nowhere to put your database access code except in your App.BusinessLogic assembly.

Perhaps you really need to rename App.Data to App.Model (or something similar), and have a new App.DataAccess assembly that talks to the database (perhaps implementing a Repository pattern). Having done that, I would split things up like this:

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. App.Model
5. App.BusinessLogic

Answer 3

I would probably go with

1. Data
2. Data
3. Data, although I'm not entirely sure what the class is doing
4. Data
5. BusinessLogic

Answer 4

1. -> App.Data
2. -> App.Data
3. -> App.BusinessLogic or App.Data - not sure exactly what this means.
4. -> App.BusinessLogic
5. -> App.BusinessLogic