I decided to do some digging into the LLBL framework today. I'm thinking of designing a similar framework for crystal reports for an up comming project. I'm also researching common design patterns. (I should start to use these, they make life so much easier).

So in my research I have come across programming to an interface/abstract rather than a concrete object. This is great for polymorphing, and creating stubs for testing.

why are entity specific interfaces not generated and included in the entity itself? example

namespace DbGeneric.EntityInterfaces
{
     public interface IRegionEntity
     {
          int RegionId { get; set; }
          int RegionName { get; set; }
     }

     public interface ICustomerEntity
     {
          int CustomerId { get; set; }
          int CustomerName { get; set; }
          IRegionEntity { get; set; }
     }
}

then in the entity class it would look like

namesapce DbGeneric.EntityClasses
{
     public Class RegionEntity: BaseEntity2, ISerializable, IRegionEntity
     {
          ....
     }  
}

the same would be true for entityviews, and typedlists. wouldn't this provide a simpler way to create stubs for testing? of course LLBL is a coding layer between db and GUI, so to test you would want to great a test db with dummy data. not necessarily test to an entity specific interface... does that make sense?

more than likely I just haven't grasped the whole concept with all the patterns, practices and real world implementations.

Why would you need this?

Since each Entity is unique so would be the interfaces? Having a matching interface is just redundent in this case. Bascially each interface would only be implemented by a single Entity class.

BOb

I understand. I was reading up on programming to interfaces/abstractions intead of concrete objects. I guess I[X]Entity would be an extreme instance of that.

If you ask me it makes sense to interface an Entity if you look at it as a DataContainer e.g DTO.

Outside you BL you just program against the public interface and inside the BL you work with LLBLEntites which of course implement the public interface.... IMHO this leads to a cleaner separation...

Adrian

adrianporger wrote:

Outside you BL you just program against the public interface

OK, but you still need to create a concrete object outside the BL. so you would have the following objects I[X]Entity = shared interface [X]Entity = LLBL object inside BL [X]EntityDTO = object outside BL

in this instance you are programming to the interface. however this also creates a level of complexity that may not be needed since you could also pass the XEntity object from BL to PL. Since it's a 1:1 mapping it seems overkill. I'm not directly remoting/serialize any objects either so this overhead wouldn't be an issue.

However I[X]Entity would allow me to create a new BL layer and not impact the PL too much. the PL would need to be informed of the new BL. I also don't see a need to be LLBL egnostic. LLBL is another tool just like .net, crystal and sql server, so I would need to be transparent to LLBL.

Well you are right I meant to use an Interface(using factories or DI for instantiation) or public DTO/abstract classes. Using both concepts is indeed a bit redundant..

Advantage is that you don´t have to reference ORMSupport in the PL and furthermore the PL is completely agnostic of the BL internal workings... e.g. LLBLGen. The main advantage arises when working in separate teams one for the PL one for the BL. Using interfaces the PL team is capable of doing unit -tests(using mock up objects) without the knowledge of LLBL etc. Same goes for the BL team.

I think this is the main concept of Contract first design (CFD)...

adrainporgoer wrote:

The main advantage arises when working in separate teams one for the PL one for the BL

OK, that makes sense, I'm the only developer here, so this isn't an issue.

adrainporgoer wrote:

Contract first design (CFD)

I'll look into this pattern.

thanks for your insights

adrianporger wrote:

If you ask me it makes sense to interface an Entity if you look at it as a DataContainer e.g DTO.

Unless more than one class implements the interface, then the interface is redundent. The interface doesn't "contain" anything, it can't be instantiated.

It sounds like you are saying you want to create an interface to Hide the methods/properties that you don't want the UI layer to deal with. You are much better off using correct visibility scoping on your members if that is what you are looking for.

BOb

PilotBob wrote:

correct visibility scoping

I haven't heard of this. Are these attributes of some type?

PilotBob wrote:

adrianporger wrote:

If you ask me it makes sense to interface an Entity if you look at it as a DataContainer e.g DTO.

Unless more than one class implements the interface, then the interface is redundent. The interface doesn't "contain" anything, it can't be instantiated.

It sounds like you are saying you want to create an interface to Hide the methods/properties that you don't want the UI layer to deal with. You are much better off using correct visibility scoping on your members if that is what you are looking for.

BOb

The idea behind that is to have a Contract (the interface) which must be fulfilled and that´s the only thing one component knows about the other... Most common Dependency Injection (DI) with the help of IoC Containers like Spring.Net / Structuremap / ObjectBuilder(EntLib3) is used to accomplish the creation of objects...

you can find a quick summary about it here : David Hayden blog

and here

Ralf Westphals blog

Adrian

thanks for your insights on this topic. I've spent the last 2 days researching IoC and DI and MVP and the like. here are some followup questions/insights I have.

1. I think what I'm looking for in terms of I[X]Entity is the interface(view) between my PAL and BLL. I realized this doesn't need to directly implement all the properties of a given entity. Infact a property of my interface(view) could be an entity. I would still get the benefits of ORMSupport in my PAL. By using these complex types my interface becomes "smarter" then a pure MVP implementation as now some operations must be done before passing information along to the BLL.

2. IoC and DI are still confusing me to no end in pratical terms. Conptutally I get it, implementation/syntax... I'm still fuzzy. the XML configuration is starting to make sense. I've done most of my research on Spring.Net. 2.1. What are some other IoC/DI frameworks for .Net 2.0? 2.2. If all of this information is configured dynamically then you won't get compile errors, correct? errors would occur at runtime, correct?

3. I found this post [http://www.codeproject.com/useritems/ModelViewPresenter.asp] which I found very helpful. It also pointed me to PageMethods which appear to be a great tool for web apps.

4. MVP pattern. is the presenter also the business logic? or would the presenter link the view to the business logic? I guess more like a controller in MVC? A. One thought is the presenter is the bll. any view that needed it's logic would call that presenter. -or- B. the presenter hooks the view to the business logic. this would allow the business logic to be shared with multiple presenters. So far I think A is correct, at least right now. B seems overly complex.

5. with all this focus on PAL/BLL communication, what about applying CFD between the BLL and DAL? Since LLBL is my DAL would LLBL interfaces be my contracts between BLL and DAL? If so how would I know the correct concrete objects are instanciated(sp)?

As I write this post I just had a thought about IoC/DI. The framework uses the factory pattern to create the instance I need at runtime correct? And if that's the case the my paratmeters to determine what type of object to return are determined by the config file, correct?

I think these concepts/patterns are starting to click with me Now I just need to implment them in my next project.

As I write this post I just had a thought about IoC/DI. The framework uses the factory pattern to create the instance I need at runtime correct? And if that's the case the my paratmeters to determine what type of object to return are determined by the config file, correct?

I think these concepts/patterns are starting to click with me Now I just need to implment them in my next project.

Great to see you dig into this complex material!

2.1. What are some other IoC/DI frameworks for .Net 2.0?

As far as I know there is structuremap and Castle Windsor as great alternatives in the open source sector.. MS is building a Enterprise Library Block called ObjectBuilder which supports the creation of IoC Container but not itself is a DI Framework like Spring.net

You can also use plain .Net using the reflection API Object Activator.Create(T as Type) if you don´t want to make another dependency to a framework...

2.2. If all of this information is configured dynamically then you won't get compile errors, correct? errors would occur at runtime, correct?

That´s right ! You loose compile time error checking but with Test Driven Design e.g UnitTests for your components this is acceptable. Please note that using IoC containers on small Apps could be an overkill!

3. I found this post [http://www.codeproject.com/useritems/ModelViewPresenter.asp] which I found very helpful. It also pointed me to PageMethods which appear to be a great tool for web apps.

Take a look at the Web Client Software Factory from the MS p&p team! They provide a good start for building MVP Web Applications. (http://msdn2.microsoft.com/en-us/library/bb264518.aspx)

4. MVP pattern. is the presenter also the business logic? or would the presenter link the view to the business logic? I guess more like a controller in MVC? A. One thought is the presenter is the bll. any view that needed it's logic would call that presenter. -or- B. the presenter hooks the view to the business logic. this would allow the business logic to be shared with multiple presenters.

Well as always it depends on the granularity you look at the application. IMHO the BLL is living on the Application server and handles Business and Infrastructure work like Validation, CRUD operations, Authorisation/Authentication, Logging, Caching, Auditing, etc.

The presenter is living in the WebApp solution and manages the views...(say if button1 is clicked open view2 or if user A has no authorisation hide menuitem B etc.)

5. with all this focus on PAL/BLL communication, what about applying CFD between the BLL and DAL? Since LLBL is my DAL would LLBL interfaces be my contracts between BLL and DAL? If so how would I know the correct concrete objects are instanciated(sp)?

To make your live easier I would suggest to only interface/contract the BLL/PL tiers as you could rely on LLBLGen to work properly.. But that´s just a suggestion!

adrianporger wrote:

That´s right ! You loose compile time error checking but with Test Driven Design e.g UnitTests for your components this is acceptable. Please note that using IoC containers on small Apps could be an overkill!

I figured it would be. I just have to determine what is "small", "medium" and "large".

adrianporger wrote:

Take a look at the Web Client Software Factory from the MS p&p team! They provide a good start for building MVP Web Applications. (http://msdn2.microsoft.com/en-us/library/bb264518.aspx)

I have read some articles by David Hayden about the WCSF. This relys on Ent Lib 3.0 and .Net 3.0 correct? .Net 3.0 has a full release, but I think WCSF is still in Beta. I worked through the pains of MS AJAX from Atlas to RC1. If it is in Beta, I'll wait for a full release.

adrianporger wrote:

Well as always it depends on the granularity you look at the application. IMHO the BLL is living on the Application server and handles Business and Infrastructure work like Validation, CRUD operations, Authorisation/Authentication, Logging, Caching, Auditing, etc.

The presenter is living in the WebApp solution and manages the views...(say if button1 is clicked open view2 or if user A has no authorisation hide menuitem B etc.)

If my presenters are part of the webapp itself, then I would need all new presenters if I wanted a different GUI. Part of me says this is unacceptable from a theory stand point as the GUI should not be dicated by how the logic is accessed. But the "real life" developer in me says... "that's nice in theory, but...". In reality there is still a significant difference between GUIs and this isn't all that practical.

One last question concerning Spring.Net/Castle Winsdor. Do these framework tie the view to the presentation or the presentation to the view?

My understanding is the DI framework is accessed within the concrete view. The framework would create an instance of the presenter. This would make sense since the concrete view requires a presenter to do any real processing. The presenter doesn't need to know what the concrete view is, only what the contract for a view is.

from within my code it would look something like this.

Public class MyGUI: IMyGUIView
{
     //private variable for my controler

    Page_Load(object sender, EventArgs e)
    {
          //DI framework call to inject concrete controler type
    }
    ....
}

This still leaves me with the question... what object type is the presenter? example: private [presenter type] presenter; I guess the presenters have interfaces as well? and the interface is the variable type within the view? example: private IPresenter presenter;

I have read some articles by David Hayden about the WCSF. This relys on Ent Lib 3.0 and .Net 3.0 correct? .Net 3.0 has a full release, but I think WCSF is still in Beta. I worked through the pains of MS AJAX from Atlas to RC1. If it is in Beta, I'll wait for a full release.

As far as I know it´s not beta! It is a good primer on MVP WebApps in the .Net World besides MonoRail...

I recommend to give it a try since it does create(unfold) a good starting point to work with.

Adrian

I've reviewed StructureMap, Spring.Net, and Castle Winsdor. Right now I think a full MVP DI implementation is more complexity than I need for my current project. It also seems that adding a DI framework won't be too difficult, once an MVP pattern is in place.

At the surface all three frameworks seem the same. they all: have an Object factory. use an xml file to create instances allow for arguements to be assigned in the constructor.

with this all being even the differences seem to be: active community involvement documentation product stability

what are your experiences, if any, with these frameworks? At this point I am interested in the framework that is (order of importance): 1. stable 2. well supported (docs/community) 3. light weight

how would you pass the view using the "this" keyword to the presenter Ctor using DI? would it look something like:

public class MyView: System.Web.Page, IView
{
       private IPresenter _presenter;

       protected override void OnLoad(EventArgs e)
       {
              MyPresenter = DI.ObjectFactory.Create("MyPresenterType", this);
       }
}

this assumes the presenter constructor looks like:

public class MyPresenterType: IPresenter
{
     private IView _view;
     MyPresenterType(IView view)
     {
     this._view = view;
     }
}

jmeckley wrote:

PilotBob wrote:

correct visibility scoping

I haven't heard of this. Are these attributes of some type?

I'm sure you heard of them, perhaps not by that name. You can specify the visibility of each class and it's members using the visiblity modifier. In C# they would be...

Public - any layer/class can see or access Internal - only classes in the same assembly can see or access Protected - only subclasses can see or access Protected Internal - only subclasses in the same assembly can see or access Private - only the declaring class can see or access

So, the only items in your Entitiy objects that should be public are those that your UI layer needs to see or access. Anything else that you only want visisable to your business layer would be Internal.

Some people build a seperate business layer so the UI layer doesn't even reference the LLBLGen objects.

BOb

jmeckley wrote:

1. I think what I'm looking for in terms of I[X]Entity is the interface(view) between my PAL and BLL. I realized this doesn't need to directly implement all the properties of a given entity. Infact a property of my interface(view) could be an entity. I would still get the benefits of ORMSupport in my PAL. By using these complex types my interface becomes "smarter" then a pure MVP implementation as now some operations must be done before passing information along to the BLL.

Remember the LLBLGen entities would be considered the "Model" objects in MVC/MVP pattern. In both of those patterns the View doesn't know anything about nor interface with the model.

jmeckley wrote:

2. IoC and DI are still confusing me to no end in pratical terms. Conptutally I get it, implementation/syntax... I'm still fuzzy. the XML configuration is starting to make sense. I've done most of my research on Spring.Net.

Some one else mentioned the popular ones. What I would say is the average person writing a single purpose application wouldn't need this stuff. It generally comes when you are building very polymorphic stuff, for example, supporting multiple DBMS's or wanting to change the behavior of stuff on the fly. Etc.

jmeckley wrote:

4. MVP pattern. is the presenter also the business logic? or would the presenter link the view to the business logic? I guess more like a controller in MVC? A. One thought is the presenter is the bll. any view that needed it's logic would call that presenter.

No, the presenter is considered part of the user interface (UI) layer. It contains "UI" logic that would be common to different views or UI layers. MS has also called this the User Interface Process layer in some of the patterns and pratices white papers.

jmeckley wrote:

B. the presenter hooks the view to the business logic. this would allow the business logic to be shared with multiple presenters. So far I think A is correct, at least right now. B seems overly complex.

Right, the presenter is the guy that gets the model and provides it to the view. As said about all your UI login is put into the presenter. You could have multiple views using one presenter.

jmeckley wrote:

5. with all this focus on PAL/BLL communication, what about applying CFD between the BLL and DAL? Since LLBL is my DAL would LLBL interfaces be my contracts between BLL and DAL? If so how would I know the correct concrete objects are instanciated(sp)?

I really consider the LLBLGen entities the Model and the ORM/Adapter the DAL... these two combined the Business Layer. You reallty can use LLBLGen entities and "swap out" the DAL, since they are very tightly coupled. That said, LLBLGen gives you the benefits of being able to swap out the DAL, espesially with the Adapter templates by providing seperate Code for each back end you need to use, for example.

BOb

PilotBob wrote:

I'm sure you heard of them, perhaps not by that name. You can specify the visibility of each class and it's members using the visiblity modifier. In C# they would be...

Public - any layer/class can see or access Internal - only classes in the same assembly can see or access Protected - only subclasses can see or access Protected Internal - only subclasses in the same assembly can see or access Private - only the declaring class can see or access

OK, now I know what you mean.

PilotBob wrote:

Remember the LLBLGen entities would be considered the "Model" objects in MVC/MVP pattern. In both of those patterns the View doesn't know anything about nor interface with the model.

OK, in it's purest form I agree. Ultimately you would need DTOs to transfer data from layer to layer... why couldn't the entitys be concidered the DTO. Granted they are "heavy" objects just for DTO's. I could look into the LLBL DTO templates. These could be used by the PAL/GUI. I'll need to tinker with Template Studio.

I've decided that a DI framework is overkill. Maybe I'll experiment with it on another project.

Now it's time to research DTO generation.

Thank you,

jmeckley wrote:

Ultimately you would need DTOs to transfer data from layer to layer... why couldn't the entitys be concidered the DTO.

Well, yes an no. You could treat the Entity as a DTO, but generally when people say DTO they are talking about light weight classes that derive from Object and only have fields in them... alot of people use Structs for this since they are more easily managed in memory.

MVC or MVP doesn't really "pass" data to another layer. The controller/presenter instantiates the Model (entity object) and sets the views properties (databind) with data from the model. So there is not really any passing of an object such as a DTO. Some MVC/MVP frameworks such as Monorail or Ruby On Rails automate binding the model's data to the view so you don't need to write alot of code in your controller to do it.

A DTO might be used if you are doing remoting and you want to pass a simple object containing your data from the middle tier to the client tier.

You should go to www.dnrtv.com and watch the episode on MVP so you can see this stuff in action.

BOb

adrianporger wrote:

I have read some articles by David Hayden about the WCSF. This relys on Ent Lib 3.0 and .Net 3.0 correct? .Net 3.0 has a full release, but I think WCSF is still in Beta. I worked through the pains of MS AJAX from Atlas to RC1. If it is in Beta, I'll wait for a full release.

As far as I know it´s not beta! It is a good primer on MVP WebApps in the .Net World besides MonoRail...

WCSF is currently a CTP .Net 3.0 is released Enterprise Framework for .Net 2.0 is released

WCSF relies on the Guidance Automation Extensions and the Guidance Automation Toolkit which are also a CTP version currenlty.

I think all these CTP items are scheduled to release this summer sometime.

BOb

My $.02 coming in late to the party...

• DI is useful not just for larger, more complex projects, but also as a means of simplifying unit testing by allowing you to substitute a mock object within the test libraries.

• To gain the full benefits of DI, you need to use a full DI framework and/or IoC container. The reason for this is that you need to be able to configure at runtime which instance is returned from the container.

• Even in the absence of a DI framework, merely establishing the pattern of supplying depdencies to dependent objects improves your code design, increases readability, improves flexibility, and reduces coupling. However, for anything larger than a small project a DI framework is highly recommended.

• MVP is can be simply described as "The Humble Dialog Box". Do a search on it. The idea is that the Presenter is passed an implementation of IView and directly controls it. The Presenter itself is simply pulling out presentation logic from the view to allow you to better unit test the GUI and/or swap views if needed. It does not provide business logic support, just UI logic.

• The entities themselves are not business objects. They become business objects (especially in the domain sense) when business logic is added. As such they are merely containers for data - direct reflections of the database. They can be used as DTOs or they can have business logic added to turn them into business objects.

Jeff

jeffreygg, thank you for your insight. this thread has definately improved my understanding of how these theorys/methods/frameworks can be implemented.

after much concideration I'm going to setup my next project like this: * GUI (Web App) * PAL (Presenter objects) * BLL (Business Logic/Actions on DbGeneric) * DAL (DbSpecific) * Database (Sql Server)I think that covers it.

using the codeproject link above I can control page flow by delegating a presenter event to the view. Using PageMethod [http://metasapiens.com/PageMethods] I can reduce navigation errors even more. But this is just a GUI thing and slightly off topic.

My BLL will be EntityMangers, but not like the Manger Templates available in the 3rd party section. They seem a bit vague for me. Mine will preform the specific tasks I require. (this shouldn't be a surprise... it's where the heart of the system lies )

If figured in my scenario a DI framework would only be useful for unit testing. Once the system is in place logic doesn't need to change on the fly. Since the system is small(tiny) and there are plenty of new techniques I'm trying to implement I hold off on DI for now.

DI will be coming with v2.1 of LLBLGen Pro btw.

Otis, I've been following the DI v2.1 threads to some extent. I thought the DI framework would only apply to LLBL objects, not an entire project/solution.

jmeckley wrote:

Otis, I've been following the DI v2.1 threads to some extent. I thought the DI framework would only apply to LLBL objects, not an entire project/solution.

You can call the injection routine from within your own classes as well. (or from whatever external class you have to inject DI info into an object, thus for example a factory)