Best Practices: Web Application with Class Library for Business Logic

Requirements
RadControls version 2009 Q2
.NET version 3.5
Visual Studio version 2008
programming language C#
browser support	all browsers supported by RadControls

PROJECT DESCRIPTION
In a medium scale application (and for large scale applications) you should build a class library for your business logic.

In this case I have the following:
1) EntityModel = open access persistent classes
2) DataAccess = open access DAL
3) BusinessLayer = My business logic

After reading all the best practices KB, I started implementing my business logic with a common base class that offers all of the scope related operations for the current http request.

here is the code for my BusinessBase class:

Every Business Object that implements my business logic in this class library is derived from this class, and then i can simply use the defined scope.

For example:

I leave it to the user of the business logic to decide where to start or commit transactions (sometimes i want to commit before other db operations and not necessarily upon dispose).
for example:

This example is one of the best here. Any chance of update it with the new Domain Model approach applied to a web app?

Hello Hugo Augusto,

Sure, we will update the example in a few days. We are quite busy preparing the Q2 release at the moment. Thank you for the request.

All the best,
Damyan Bogoev
the Telerik team

Hello Hugo Augusto,

We have uploaded the following code library example: "Best Practices in web development with OpenAccess" where the requested from you scenario is demonstrated using the OpenAccessContext.
I hope this example resembles the one that you have requested.

Regards,
Damyan Bogoev
the Telerik team

Hi Damyan,

in the example I believe there is an error. In BestPracticesMasterPage, Default.aspx.cs, you have in Page_Load event,


Shouldn't this be


Also, I'm having serious doubts about using OpenAccess the way you do. I believe that those who are using ORM's need some abstraction when using them so that we will be able to easily replace the current ORM with another one. Using this same example, what would be your suggestion to allow for absolutely zero coupling with the domain model (Open Access generated Model). The example in this website is exactly what I mean, and would love to see that implemented here with OpenAccess. Also, manually creating Assembler classes with the mapping from the Generated Domain Model classes to our own business object classes as I already saw, is absolutely insane if you have many tables and relations. If I have to make the mapping manually, what's the point of using an ORM? I'm not in any way criticizing OpenAccess, but just trying to get some discussion about this.

Once again, it would be great to see an example addressing this issues.

PS: I would also love to hear what you think about returning IQueryable<T> to the upper layers from an existing List of objects instead of a collection of objects like "TestingPersonList" or even the usual List<>.

Hi Hugo Augusto,

1. Using the following code snippet in the Page_Load method:


we are retrieving the first person from the collection, change its name and then persist the change to the database with the SaveChanges method.
This example demonstrates how to use the OpenAccessContext, not the IObjectScope .
2. You could find useful the following code library example which demonstrates how to implement a context factory using Telerik OpenAccess ORM. Another code library which uses a repository pattern can be found here but it is used in a scenario with WPF.
3. Passing an IQueryable instance is better approach than a List instance. When a List instance is passed all the data should be fetched and passed, while the IQueryable will give you the ability to fetch the data you need in the upper layer.
Hope that helps.

All the best,
Damyan Bogoev
the Telerik team

This is an excellent article for getting a quick web framework in place! I used it and it saved my butt under a deadline. 

I do have one point. I am not sure of the implications of this - so maybe someone can give their thoughts.

What about using System.Web.HttpRuntime.Cache instead of HttpContext. The HttpContext is not always guarenteed to be there, and is not there in many WCF implementations. What System.Web.HttpRuntime.Cache attaches it to the IIS runtime directly.

What about this as a constructor?

Hello Solomon,

Regards,
Damyan Bogoev
the Telerik team