I'm trying to deisgn my next project using the MVP pattern. so far I know that DAL = LLBL DbSpecific. LLBL DbGeneric? BLL = Incorporates LLBL DbGeneric. references DbSpecific. an established framework, or written by me? Presenter = Writtern by me Views = Writtern by me GUI = Web App written by me

OK, so the View should not know about the model. First model is vauge. is the model LLBL? is it the BL? is it both? The presenter obviously knows about the Model, that's how the presenter communicates with the db.

LLBL has many features, more on the way in v2.1! With this in mind. Is LLBL and the BL merging into 1 project?

I've done some research on CSLA. It seems most of the features CSLA provides will be available in v2.1. Maybe I'm confusing the v2.1 DI framework with the features of CSLA. It does appear I won't truely understand CSLA unless I purchase the book . Now there is also JCL which is LLBL wrapped in CSLA. Is this worth the complexity?

Ultimately it comes down to this... My View shouldn't know about my model. That being said I seem to have 3 choices. 1. use simple objects( int, string, datetime) and enumerable objects (datatset, datatable, List<T>) in my view 2. use DTOs and List<DTOs> 3. use ORMSupportClasses

If I go with option 1. I loose all my compile time exception checks for the View/Presenter/GUI in terms of datatables. using LLBL so much, I like compile time checks

If I go with option 2. they could be part of the View project. both the GUI and the Presenter rely on the View so this makes logical sense, correct? The DTOs would be checked at compile time and have type specific properties. and it makes it easier to convert/ pass object to and from the BLL. Should the BLL accept DTOs or Entities? * If DTOs then DTOs should be their own project referenced by View, Presenter, GUI and BL Managers. * If Entities than Presenter must know about the BLL and DbGeneric. Should the PAL know about DTOs and Entities, or just DTOs? * If Entities than Presenter must know about the BLL and DbGeneric. * If it only knows about DTOs then the BLL must know about DTOs, or accept simple types. I don't like that, too many objects.option 3. is already in place, just reference the assembly. but wouldn't this mean my layers are interlaced through out the project? It's referenced in just about every project that is part of the solution. If I use IEntity2 and IEntityCollection2 as my view I have to define many properities and function i'm sure I won't need. Plus they are generic, so I won't have compile time checks.

Am I making this more difficult that it needs to be for MVP to work? The more I type the more I think: * BLL = DbGeneric and my custom routines. along with logging errors/events still not sure if I want JCL for this or not. Currently I use EntLib 2.0 for logging and execption handling.

• The Presenter should nknow about DbGeneric. The BLL should accept Entities/TypedLists/TypedViews as argurements instead of simple types when appropiate.
• Presenter should transform Entities into simple objects for the View, and weak typed DataTables for TypedLists and EntityCollections. I could go with List<DTO> for EntityCollections, but don't know if it's worth the trouble.what are your thoughts?

Hi,

As far as I know in the MVP (MVC) pattern:

Model: Could be any LLBL entity, entityCollection, TypedList, etc. View: The UI windows form or ASP.Net page. Does not know about model objects. All the controls in the form or page should be public (to allow the access from controller). Presenter or Controller: Know about model and view objects. Request model objects from BL objects. Bind model objects to view's controls. Handles events rised by view's controls. Update models objects via BL.

Rogelio wrote:

Hi,

As far as I know in the MVP (MVC) pattern:

Model: Could be any LLBL entity, entityCollection, TypedList, etc. View: The UI windows form or ASP.Net page. Does not know about model objects. All the controls in the form or page should be public (to allow the access from controller). Presenter or Controller: Know about model and view objects. Request model objects from BL objects. Bind model objects to view's controls. Handles events rised by view's controls. Update models objects via BL.

If you want to be really annoyingly decoupled you can also use Adapter objects to connect your View and Controller pieces. That way the Controller isn't linked to any specific view.

Thank you for your responses. I realized I was making my project more difficult than it needed to be.

MVC / MVP is important as keeping things separated has a lot of benefits, especially the capability to do test driven development.

Based on my limited time working with LLBL, I have to say I'm quite happy with LLBL as the model, I looked at MVC for the framework, but I'm not keen on hand coding all my view pages. Yes it generates the code, but then you need to tweek it, or maniplutate the code generators and end up with 200+ of them for a sizable application. Anyways the MVC framework supported by Microsoft has some limitations I think when you want to support your application.

So I'm now looking more towards a MVP system, this should give the benefits of using WebForms. One of my headaches with WebForms is the tweeking you need to do, such as when you have a text area or a bit field, it would be nice to say for this bit field name "isPosted" make it a check box, for "Description" make it a multi-line 550 w x 75 h area. Those types of things could easily be done with a little meta system. (yes I've diverged here a bit....) So today is looking for MVP and meta data managers (for lack of a better name).

Anyone built any of these or have links to where I should explore it would be great.