Presentation and DataLayer Frameworks

Ashraf Ali posted on Wednesday, August 16, 2006

I was reading the VB2005 Business objects book (ofcourse by Rocky) :)

Rocky has mentioned something about the importance of frameworks for presentation layer and datalayer,as we already have atleast one for business layer (again by Rock).

Any one here knows about such frameworks (for presentation and datalayer)?

Rocky can you please comment on this?

Thanks

Ash

 

DesNolan replied on Wednesday, August 16, 2006

Hi,

In a sense Windows or your Internet browser are the presentation layers. However, for  additional help with working with Windows you cold look at the Micorsoft Enterprise Library and their CAB module. The Microsoft Enterprise Library 'framework modules' are free to download and complementatry to CSLA. Can't speak to the Web world, as I don't currently do much in that arena.

CSLA folds the data access layer into the Data Portal and the four Data Access methods on each Business Object. There are other tools that will abstract data access to another level also, but in my experience doing so is really worth it unless you are writing a commercial prodcut which will be required to go against different DBMS's e.g. SQL Server and Oracle.

Cheers,

Des Nolan

Ashraf Ali replied on Wednesday, August 16, 2006

Des, I appreciate your response, I would like to hear your ideas about integrating CSLA with Enterprise Library as I have never done this but would love to do it, if I get some guidance.

The reason I never tried doing so is my meager experience with Enterprise library shows that it relied heavily on dataset (forgive me If I am wrong, especially for updates) and CSLA is all about intelligent business objects, so I always thought it would kind of hard to attempt that, but since I am not very experienced with CSLA nor with Entlib so that’s my fault but please go ahead and share you experience integrating both.

Thanks

Ash

 

 

tetranz replied on Wednesday, August 16, 2006

I previously used the EntLib data access block in my CSLA BOs. It seemed like a cool idea at the time but I was really only using the Database.Execute methods where you can give it a stored procedure and a simple array of objects in the correct order for parameters and EntLib would "discover" the parameter types etc without me having to mess with SQLParameter objects. That would return a DataReader.

That worked fine until I tried the new TransactionScope in CSLA 2. I'm using SQL Server 2000 and Florin Lazar's method that Rocky provided a pointer to http://blogs.msdn.com/florinlazar/archive/2005/09/29/475546.aspx  Maybe I was doing something wrong but I couldn't get it to work at all on SQL 2000 and on a test SQL 2005 I have, it would always needlessly escalate to a distributed transaction. I gave up on EntLib data access because I discovered that it was just as easy to do the parameter discovery myself using SqlCommandBuilder.DeriveParameters() and I didn't really need the potential support for other databases. I built a simple parameter cache so it didn't have to do it every time.

I still use the exception and logging blocks to log and email exceptions.

Cheers
Ross

Ashraf Ali:

Des, I appreciate your response, I would like to hear your ideas about integrating CSLA with Enterprise Library as I have never done this but would love to do it, if I get some guidance.

The reason I never tried doing so is my meager experience with Enterprise library shows that it relied heavily on dataset (forgive me If I am wrong, especially for updates) and CSLA is all about intelligent business objects, so I always thought it would kind of hard to attempt that, but since I am not very experienced with CSLA nor with Entlib so that’s my fault but please go ahead and share you experience integrating both.

Ashraf Ali replied on Wednesday, August 16, 2006

Sweet! it means we can just avoid using enterprise library (with CSLA) atleast for data access, I would appreciate if other folks reading this also share their experiences

Ash

 

Igor replied on Wednesday, August 16, 2006

I see data access very much like  Des Nolan. For this reason I am not interested in CodeSmith (well, as far as I know, people use CodeSmith for generating table-like objects; I might be missing something here), and I do not use EntLib's DA block.

I do use EntLib's Exception Handling block, which is called both by UI code and by DataPortal.Create/Fetch/Update/Delete methods (the last chance to catch server-specific info). Btw, these server-side hooks are the only modifications that I have made to CSLA (which, actually, do not touch CSLA's core functionality).

Igor

 

SonOfPirate replied on Thursday, August 17, 2006

Three points:

1. We have made extensive use of the Enterprise Library components without any issues. Part of the reason is the convenience, another is the distinct possibility that these components will eventually be rolled into the .NET Framework - as evidenced by the new System.Configuration namespace.  Using the EntLib will (hopefully) make that transition easier.  We make use of all the .NET 2.0 components in some fashion.  It's all just a matter of where you place the "hooks" to tie it into your architecture.

2. There was an earlier statement that Windows or IE are the presentation layer.  This is incorrect and misleading.  These are "clients" but are not what is considered the Presentation Layer for application development.  The Windows Forms and Web server controls you use to build your application make up your application's presentation layer.  A solid framework for the Presentation Layer would consist of a suite of controls/components that you use to build the user-interface of your applications.  A UI framework allows you to have a consistent look-&-feel across forms/pages and applications.  For instance, prior to .NET 2.0, many web developers created their own stock Login control and included it in their UI framework so that they could simply reuse it across all of their apps.  This commonality is why you find it now a part of the base framework.

Your UI framework can be as simple as you want or as complex as you want.  We have everything from a basic image control that adds a couple of properties to the built-in image control to multi-field data entry forms (like a standard address block) with validation, etc. built-in for easy reuse.

Most UI frameworks are developed over time as need dictates.  You will find that you are reusing the same control or cutting and pasting code from app to app that could easily be centralized, etc.  Those practices lend themselves to developing a UI framework.

There are also many, many third-party products, such as Infragistics NetAdvantage, that can be used for your UI framework.  The advantage of this approach is that they've already done the work and will supply you with bug fixes and upgrades making implementation much...less painful :-)  However, you may still find the need to customize these controls to suit your needs and wind up with a set of custom UI controls based on these components rather than the .NET controls.  Either way, it helps you develop your applications quicker and with more consistency to the UI.

3. While I agree that using the EntLib Data Access Library is undesirable, it has also been mistated that the data portal mechanism in CSLA (with the Create/Fetch/Update/Delete methods) comprises your data access framework.  This is not the case.  The data portal is simply a mechanism that allows mobile business objects and distributed applications.  You still have to program the necessary data access code into the data portal methods.  That is where your data access framework comes in.  It can be as simple as making use of the built-in ADO.NET classes, using the Enterprise Library or (as we've done) developing your own set of objects.  In our case, data-agnosticity was critical.  So, we developed a framework that sits atop ADO.NET and handles the rigors of making sure that our business objects don't need to worry about the actual data source being used.  So, instead of referring to a SqlConnection object in our DataPortal_Fetch method, we use the IDbConnection and allow our framework to create a connection object of the correct type - be it SqlConnection, OracleConnection, MySqlConnection or even (our own) ExcelConnection.  Having such a framework has allowed us to create extensions, such as our Data.Excel namespace, to the built-in features so that we can better accomplish our goals.  And, we can switch an application from SQL Server to Oracle by simply changing a configuration setting - no recompilation or redeployment.  That is the power and benefit of a good framework.

 

In both of these cases, extending CSLA to include a presentation/UI framework and data access framework is as easy as adding them to your library.  At last count, we have over 500 objects in our framework which includes our hybrid version of CSLA, our stock UI components, data access, security, etc. - everything we need to quickly build consistent, stable and robust applications.  These objects all work together just as the .NET Framework objects do.  Remember, CSLA is only one piece of a full framework and handles that middle tier, the Business Logic Layer.  You still have to handle the other two (Presentation & Data) when creating your applications.  So, extending CSLA to include components for these layers makes perfect sense.

I hope that clears the air a bit and helps your understanding.

 

Brian Criswell replied on Thursday, August 17, 2006

This may be a bit pedantic, but there is a difference between the UI and presentation layers.  I would consider controls to be the UI layer and not the presentation layer.  The distinction is a bit fuzzy for WinForms, but web applications are a bit clearer as the user interface controls work on the server and the presentation layer is in the browser, merely presenting and gathering data for the UI layer.

Ashraf Ali replied on Thursday, August 17, 2006

Thanks for such thoughtful reply SonofPirate(sorry I dont know your name :)

so what I get here is for presentation layer we can either have framework using something like NetAdvantage or create our own (ofcourse over a period of time)

Coming to Data Layer framework, If I have only one type of DBMS (which is SQL Server luckily) what would you suggest to use (native ADO.NET may be)? ( I am using CSLA as business layer)

Another thing , Is anyone out there who has writtten a book (or something :) telling us how to create  a dataaccess or presentation Layer framework (like Rocky has done so for Business layer)?

This might sound a little stupid but considering the fact that I don't have 10/20 years experience, it would really help me (and other developers with less experience)

Thanks

Ash

SonOfPirate replied on Tuesday, August 22, 2006

Sorry for the delay responding, Ash - was out of town for the weekend and away from the computer.

I am not aware of any books covering the data access layer the way Rocky has covered the business layer.  Most everything I have come by explains how to use ADO.NET.  But...

In reality, any data access framework you would create is going to ultimately rely on ADO.NET for the actual work.  Even if you create your own objects, as some of the nice people at MySql have been doing, you are still going to make use of the interfaces, etc. defined in the System.Data namespace and provide the same (expected) behaviors.  So, I would suggest starting there.  Get up to speed on making use of ADO.NET, then you may start to see a pattern in how you are making use of the various classes, methods, etc.  From this you will find that you can start to encapsulate some of this "commonality" into your own classes and eventually you will have a set of objects the sit between your code and ADO.NET - your own framework.

I can tell you that standardization is key to a successful data access framework.  The more you can adhere to consistent ways of performing operations, naming objects, etc., the more you will notice the pattern developing in your code and be able to see where reuse would be beneficial.

My framework consists mostly of these types of objects.  We have a custom CommandBuilder that is used by our BOs to build the IDbCommand objects (ADO.NET) used to perform each of the data access operations.  Because we have standards for how our stored procedures and parameters are named, we can make use of this helper class to perform the work for all of our data-driven objects.  On the flip side, we have an ObjectLoader class which translates the data provided from the IDataReader object returned by the command object and populates our business object's properties.  Again, because we do things consistently, we can do this.  Of course, we provide the means to override the default behavior if needed - another key to a flexible, robust and scalable framework.

My framework has evolved in the same way I've described and, having been in use for more than 6 years, it has grown in size and complexity and now provides our business objects with complete abstraction from everything underneath when used in the default fashion.  We have built-in features to allow our code to remain truly data-agnostic by incorporating all of the little differences between data sources, such as using "@" to prefix a parameter for SQL Server or "#" for Oracle.  This allows our CommandBuilder to automatically generate the right command for any data source we are using.  we can switch an application from SQL Server to Oracle without having to change any code in our application or framework.

Perhaps I should write a book!?!?!

My point is that any framework is based on experience.  In the case of CSLA, we are able to leverage Rocky's experience in developing and utilizing a tremendous business layer framework.  but frameworks for the presentation and data access layers come about in the same fashion.  And, unfortunately, without comparible books for those areas, you are left to develop your framework based on your own work (and articles and forums posts, etc) over time.

That is until I write my book, eh? 

Hope that helps.

Ashraf Ali replied on Friday, August 25, 2006

Thanks SonofPirate, I am facing an issue with the project I am working on, I would like to hear your thoughts about this,

In my project, there  are a few asp.net forms (its an ASP.NET intranet application) which are filled by a clerical staff on behalf of a client.When the staff worker gets done with the formsshe forwarded it to the manager, If the manager approves/denies it, it becomes "final". The issue is, the client may call the staff worker and would like to make some changes to her profile ( the asp.net forms), now any change should be approved/denied by the manager. The time the staff worker makes changes to the forms (on behalf of client) and the time the manager approves/denies the change, may be days apart. In the event of manager denying the change I need to roll back to the previous data , and this data is not in one sqlserver table , it may be in several tables and also invovle association tables, That was the case for denial by the manager, In case of approval by the manager , I need to keep history of the previous data,

I dont what will be the best idea to keep this data (for historical purpose and for roll back purpose).

I am thinking there might be two approaches (may sound stupid :) sorry for that)

1) To have identical tables (including association tables) in addition to the "original" tables in Sqlserver

2) The tables for which need history tracking, every record should point back to the previous record (storing the identity of the previous record).

These are just first thoughts coming to my mind,

Any suggestion would be greatly appreciated,

Thanks

Ash

tjtrapp replied on Thursday, October 04, 2007

SonOfPirate,

Excellent post, thank you for the information.  I'm performing an eval of the CSLA and EL3 and your info saved me time.  I dont work for a tech company so resuing existing frameworks will save us hours and cash. 

Anyways, your info was much appreciated - good luck w/ the book.  Post the name of it here if/when its picked up & published.

Cheers.

TJ

 

Skafa replied on Friday, October 05, 2007

I lately stumbled upon Visual Web GUI, which allows Windows Forms like designing of ASP.Net websites.

It needs some more work here and there, but they're good on their way.

check out a quick introducten here:

http://www.visualwebgui.com/Home/Introduction/tabid/314/Default.aspx