Module with more views

Aug 16, 2007 at 1:25 AM
Edited Aug 19, 2007 at 6:42 AM
Hi,

I am planning to use WCSF in my project. My project has 5-6 modules and each module contains 10-15 views, i.e. system modules contains all system related data entry screens. My systemcontroller class and systemDAO(services) for this module is becoming big as every view need to use this for create/update/delate activities. And as this is a single file, developers are facing difficulty to work individually. Becasue there in no seperate DAO for every view, I am planning to use partial classes for each table DAO. But I don't want to use partial classes. I am following CRUD example by David. Can you suggest me how to dealing with this issue?

Regards,

Surya
Aug 16, 2007 at 5:18 PM
I can't visualize the problem from your description too well, but it sounds like you know the problem - a single system facade controller and DAO that has way too much responsibility. You need to refactor those classes into smaller classes, each handling a separate concern. Look at the API and services consumed by those classes and try to divide up like minded methods and their needs into more focused use case controllers / classes. This will make them more manageable and easier to maintain.

Regards,

Dave

_________________________

David Hayden
Microsoft MVP C#
Aug 16, 2007 at 8:01 PM
Edited Aug 19, 2007 at 6:42 AM

Dave,

I have 10-15 tables which containes data of customers, address, dealers,zipcodes,cities, etc. I would like to use seperate views to insert/update/delete data for these tables. All these screens go in a single module (system mantainance). As I need to develop 10-15 views, all these views will use single controller(Ststemmantainancecontroller) and a single service DAO (systemmantainanceDAO). As per your suggestion, shall I refactor in in to small classes like customercontroller, addresscontroller, dealerscontroller etc? and have seperate DAOs?

Thank you,

Surya



DavidHayden wrote:
I can't visualize the problem from your description too well, but it sounds like you know the problem - a single system facade controller and DAO that has way too much responsibility. You need to refactor those classes into smaller classes, each handling a separate concern. Look at the API and services consumed by those classes and try to divide up like minded methods and their needs into more focused use case controllers / classes. This will make them more manageable and easier to maintain.

Regards,

Dave

_________________________

David Hayden
Microsoft MVP C#

Aug 17, 2007 at 4:28 PM
At the very least each table in the database should have its own DAO Class: CustomersDAO, AddressesDAO, DealersDAO. By all means, split that SystemsDAO into a DAO Class for each table.

Using the Data Access Guidance Package will give you the same thing, albeit it is named Respository instead of DAO. So, if you use it, you would have CustomersRepository, AddressesRepository, DealersRepository, etc. You may want to look at the Data Access Guidance Package for some code generatiion in this area if you are coding these things by hand.

Ideally you want each presenter to talk to some middle-tier class and not the DAO directly which is in the data access layer. You could create a CustomersController that handles all Customer request. It could just as easily be called CustomerManager, CustomerServices, CustomerTasks, etc. Calling it controller may confuse it with the Application Controller Pattern discussed in the WCSF, but name it what you want. If the middle-tier class does nothing but pass on the requests to each DAO, you could just have the presenter talk directly to the DAO class and refactor later to a middle-tier class if you need a place to stick business rules.

So, you might have this talking to the DAO Directly:

     public class AddCustomerPresenter : Presenter<IAddCustomerView>
     {
          private readonly ICustomerDAO _customerDAO;
 
          public AddCustomerPresenter([ServiceDependency]ICustomerDAO customerDAO)
          {
               _customerDAO = customerDAO;
          }
 
          public void OnAddCustomer()
          {
               _customerDAO.Insert(View.Customer);
          }
     }

or adding a middle-tier class:

     public class AddCustomerPresenter : Presenter<IAddCustomerView>
     {
          private readonly ICustomerTasks _customerTasks;
 
          public AddCustomerPresenter([ServiceDependency]ICustomerTasks customerTasks)
          {
               _customerTasks = customerTasks;
          }
 
          public void OnAddCustomer()
          {
               _customerTasks.Insert(View.Customer);
          }
     }

with CustomerTasks having a depenency on CustomerDAO:

     public class CustomerTasks : ICustomerTasks
     {
          private readonly ICustomerDAO _customerDAO;
          private readonly ICacheService _cacheService;
 
          public AddCustomerPresenter([ServiceDependency]ICustomerDAO customerDAO,
                                                      [ServiceDependency ICacheService cacheService)
          {
               _customerDAO = customerDAO;
               _cacheService = cacheService;
          }
 
          public void InsertCustomer(Customer customer)
          {
               _customerDAO.Insert(customer);
               _cacheService.Add("Customer: " + customer.Id.ToString(), customer);
          }
     }

I typed this up from memory and over simplified it, but you get the idea.

Same thing could work for Addresses, Dealers, etc.

Hopefully this helps.

Regards,

Dave

_________________________________

David Hayden
Microsoft MVP C#
Aug 19, 2007 at 6:40 AM
Edited Aug 19, 2007 at 6:42 AM
Dave,

Thank you very much, will follow as suggested.

Surya