Hi,

Does programming LLBLGen count as programming against a DAL or would a proper DAL require that calls to LLBLGen be encapsulated within a higher level object?

So I'd be making calls like... DAL1.GetTodaysNewsStories();

I.

A very good question, however, the answer will depend on the architectural discipline you choose. There are quite a few out there e.g. Ms, CSLA etc.

For MS application architecture blueprint and best practice see - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/apparchch2.asp or search msdn for Application Architecture for .NET: Designing Applications and Services.

Data Access layer is described:

Data access logic components. Most applications and services will need to access a data store at some point during a business process. For example, the retail application needs to retrieve product data from a database to display product details to the user, and it needs to insert order details into the database when a user places an order. It makes sense to abstract the logic necessary to access data in a separate layer of data access logic components. Doing so centralizes data access functionality and makes it easier to configure and maintain.

and BE…

Business entity components: Most applications require data to be passed between components. For example, in the retail application a list of products must be passed from the data access logic components to the user interface components so that the product list can be displayed to the users. The data is used to represent real-world business entities, such as products or orders. The business entities that are used internally in the application are usually data structures, such as DataSets, DataReaders, or Extensible Markup Language (XML) streams, but they can also be implemented using custom object-oriented classes that represent the real-world entities your application has to work with, such as a product or an order.

Based on the above, I believe that LLBL is provide BE layer functionality.

I'll take a look at that link but personally I think its probably better to encapsulate LLBLGGen code within another layer because firstly it makes the calling code cleaner and secondly it means that if two different locations within the app require the same data they can both call the same code.

Also, I can insert caching code inside the extra layer.

Ian wrote:

I'll take a look at that link but personally I think its probably better to encapsulate LLBLGGen code within another layer because firstly it makes the calling code cleaner and secondly it means that if two different locations within the app require the same data they can both call the same code.

Also, I can insert caching code inside the extra layer.

Yea, but does this need another layer. I was thinking of creating static methods on the entity objects to encapsulate this type of stuff. This would provide a clean API to the UI layer, but also not require a whole slew of new classes and layering to the system.

BOb

If you want abstraction from the 'DAL', then you might want to look at

Data Transfer Object design patern

-http://www.martinfowler.com/eaaCatalog/dataTransferObject.html. This would mean that seperate layer that all the layers have access to.

You also might want to look at http://msdn.microsoft.com/msdnmag/issues/04/12/DataPoints/. to implement strong typed data transfer object.

Yea, but does this need another layer. I was thinking of creating static methods on the entity objects to encapsulate this type of stuff. This would provide a clean API to the UI layer, but also not require a whole slew of new classes and layering to the system.

Personally I don't think it should be an entity's responsibility for doing a specific query.

Of course, one want as few classes and layers as possible but if code exists then its better to have it inside the appropriate classes and layers.

OK, I agree that LLBLGen counts as BE layer functionality. In fact, as it says in the manual, LLBL stands for Low Level Business Layer.

So, if I encapulate my LLBLGen code inside another layer so that I can insert caching and factor common queries, then what type of layer would this new layer be?

Incedentally, is it normal for folks to have their presentation layer deal directly with DataAccessAdapters and relational predicate buckets? If ones does this, then as soon as more than one web page or drop down needs the same query, then they'll be repetition of the code which describes the filter.

So personally, I don't see how a decent design can avoid adding another layer.

Ian wrote:

So, if I encapulate my LLBLGen code inside another layer so that I can insert caching and factor common queries, then what type of layer would this new layer be?

I think, if you look at it at a higher level,

LLBLGen is your Model Layer WebForm/WinForm is your View Layer

You just need to create a controller Layer. This could be encapsulated in your Web/Win Form code behind or created as a seperate class lib so you can share the controllers with Web/Win forms.

BOb

We built our project as follows using the Data Adapter:

• The LLBL code is compiled into our DAL layer.
• We have a BLL layer that is organized by functionality (not tables) that contains static methods to perform actions (get data, add data, etc.). This way, we can reuse from any page and all business logic is encapsulated here.
• Then we have our presentation layers. I say layers because we have a Web project, a windows service project and a windows app. They all call against the BLL.

So far it has worked very nicely for us. The LLBL entities are passed through all layers and are not wrapped or anything.

Hopefully within the next week or so, we will post a link to our site in the Showcases forum so you can see it.

Hey Matt,

Thanks for your reply.

What do you mean by, 'The LLBL code is compiled into our DAL layer.'? Do you mean that the generated code is your DAL layer?

The LLBL entities are passed through all layers and are not wrapped or anything.

This means that the presentation layer and the BLL layer must both be referencing the generated code. This is what I'd do but doesn't this kind of undermine the 'minimise dependencies' tenet of n-tier architecture?

Did you guys/gals have a debate over the use of static functions? Doesn't your BLL need to persist state accross method calls?

Cheers,

Ian.

Ian wrote:

What do you mean by, 'The LLBL code is compiled into our DAL layer.'? Do you mean that the generated code is your DAL layer?

Yes, that is what I was really trying to convey.

Ian wrote:

This means that the presentation layer and the BLL layer must both be referencing the generated code. This is what I'd do but doesn't this kind of undermine the 'minimise dependencies' tenet of n-tier architecture?

Correct, our presentation and BLL layers reference our DAL project. Yes, from a purist point of view, I would prefer it if the entities were at a different level or in a different assembly or namespace. However, the reality is that the entities are needed in the DAL and they provide access to all the data in the BLL and provide all the binding hooks needed for the presentation layer.

I explicitly mentioned this in my original reply because there does seem to be two camps here: Those that reference the entities in all layers and those that choose to wrap the entities before passing or using them in the presentation layer.

Ian wrote:

Did you guys have a debate over the use of static function? Doesn't your BLL need to persist state accross method calls?

I don't know that there was much debate involved. It was actually a conscious design decision to make the BLL stateless. Our BLL is really just a wrapper around the business logic for our database functions.

Hope that clarifies things.

Yeah thanks.

mattsmith321 wrote:

• The LLBL code is compiled into our DAL layer.
• We have a BLL layer that is organized by functionality (not tables) that contains static methods to perform actions (get data, add data, etc.). This way, we can reuse from any page and all business logic is encapsulated here.

Hi, Matt!

I am interested in your architecture. If I understood what you are doing, the Entity classes generated by LLBL are your DTOs (belonging to your DAL layer) and your BLL provides services in a stateless mode. But then, everytime you need a service from your BLL objects, you need to pass in the DTOs, given that your BLL is stateless, right?

Well, in this scenario, let's imagine that you have your Orders class in the BLL, with all its logic and, for example, a method called Total(), which receives an ItemsEntity object as a parameter (it needs it, as it is stateless) and iterates the ItemsEntity to return the total amount of the Order (that's a little stupid, but just an example). Well, now your web page needs to know the total amount of the order. How do you get the information? What references do you have in the web page?

Thanks!

Wouldn't Total() just return the value?

int total = BLL.Total(ItemsEntity1);

Ian wrote:

Wouldn't Total() just return the value?

int total = BLL.Total(ItemsEntity1);

That's what I imagined. But the web page would have a reference to the ItemsEntity class. That means my entity's data is being exposed to clients. Where does encapsulation fit in here?

Ian wrote: This means that the presentation layer and the BLL layer must both be referencing the generated code. This is what I'd do but doesn't this kind of undermine the 'minimise dependencies' tenet of n-tier architecture?

Correct, our presentation and BLL layers reference our DAL project. Yes, from a purist point of view, I would prefer it if the entities were at a different level or in a different assembly or namespace. However, the reality is that the entities are needed in the DAL and they provide access to all the data in the BLL and provide all the binding hooks needed for the presentation layer.

I explicitly mentioned this in my original reply because there does seem to be two camps here: Those that reference the entities in all layers and those that choose to wrap the entities before passing or using them in the presentation layer.

Isn't this the same issue that we were discussing here?