As a part of upcoming CSLA.NET 3.6 beta 2 release we have added one more feature - Csla.Net Class Templates for VB.NET and C# integrated in Visual Studio 2008.  So for example, when you select "Add New Item" in Visual Studio you get following options: 

Each of the class templates from the dialog above generates a Csla object with the template selected.  So for example, for selected CommandObject template in the dialog above with the selected name CommandObject2 you get the code generated below:

using System;
using System.Collections.Generic;
using System.Text;
using Csla;
namespace ClassLibrary1
{
[Serializable]
public class CommandObject2 : CommandBase
{
#region Authorization Methods
public static bool CanExecuteCommand()
{
// TODO: customize to check user role
//return Csla.ApplicationContext.User.IsInRole("Role");
return true;
}
#endregion
#region Factory Methods
public static bool Execute()
{
if (!CanExecuteCommand())
throw new System.Security.SecurityException("Not authorized to execute command");
CommandObject1 cmd = new CommandObject1();
cmd.BeforeServer();
cmd = DataPortal.Execute(cmd);
cmd.AfterServer();
return cmd.Result;
}
private CommandObject1()
{ 
/* require use of factory methods */ 
}
#endregion
#region Client-side Code
// TODO: add your own fields and properties
bool _result;
public bool Result
{
get { return _result; }
}
private void BeforeServer()
{
// TODO: implement code to run on client
// before server is called
}
private void AfterServer()
{
// TODO: implement code to run on client
// after server is called
}
#endregion
#region Server-side Code
protected override void DataPortal_Execute()
{
// TODO: implement code to run on server
// and set result value(s)_result = true;
}
#endregion
}
}

This is the third part in series "Implementing MVC Site using Csla and ExtJs".  The first two parts can be found here:

Part 1 - Introduction 

Part 2 - Solution Structure 

In the previous 2 posts I mentioned decisions behind some of the technologies used in the demo as well as the file structure.

 If you remember I stated that url reguest like:

http://server/<Controler>/<Action>/<Parameter(s)>

is mapped into Controller.Action(Parameters...) call.

So lets take a look at the  our example - what happens when we click on Customer link:

As you can see the url follows the pattern we mentioned above.  So with the assumption from above we would presume that the CustomerController.List() method would be called.  Lets take a source code of that Action/Method to se how do we get to the view:

Where is the beef? List method seems to create some SelectList object, and then passes it to the method called View as a parameter.  Hmmm...  OK, method View probably results in View called List being rendered, and we are passing it SelectList for perhaps databinding...

Where is CSLA code?  Well, customerFactory is an instance of ReadOnlyListFactory class.  RetreiveAll() returns CustomerList instance which is ReadOnlyBase implemenation.  But why not use  CustomerList.RetreiveAll() - factory method?  Instead of using Factory Method design patern, we are using Abstract Factory, moving Create(), and Fetch() outside of our Csla BOs, for the purpose of easier Unit Testing.  I will explain the details of this in one of the future posts that has to explain the whole process of testing all of the app layers in Csla - which will probably be the best part of this demo.

For now, all we need to know is that there is AbstracBusinesstFactory class that defines following: 

But wait, when I run the sample site the drop down I see has a different style from standard windows drop-down.  In addition to that we can see that the drop down has a type-ahead, kind of like Intelisense...

How come?  When I look at the html source very simple <select> element is rendered... 

This is the second article in "Implementing MVC Site using Csla and ExtJs".  There will be few more!  First one can be found at:

Part 1 - Introduction 

Unfortunately I have to get through this part and UI before I starttalking about my favorite parts TDD using MVC, Unit Testing in Csla,Design of the DAL in this example to support testability, and newfeatures of Csla 3.6 that support Unit Testing, like ObjectFactory. This part being UI, and how Csla BOs get rendered in MVC app that usesExtJs Ajax library.  Fortunate part about that though is that I hopemany of you will find the UI part to be something different and cool! 

So lets take a look at the ExtJsMvc solution (image on the left).  It includes 3 projects:

- ExtJsCslaDemo.Web (web site)

-  ExtJsCslaDemo.Web.Test (Unit tests library built on top of xUnit.net and RhinoMocks)

- Northwind.Data (Linq DAL + few classes that make testing a DAL breeze, on all on top of Northwind sample DB - attached in App_Datafolder)

Key to any Web MVC project are the following 3 folders:

- Controllers (controller classes are in this folder)

- Views (This folder contains all the Views/Pages to be rendered inthis application.  Views are grouped in Subfolders that hold the samename as a controller that is in charge of that view.  SO for example,you have a Customer subfolder of the Views folder that holds veiws thatthe CustomerController controls - a single veiw called List.aspx).

- Models (This is the place for your BOs that the Views will render- in this example, this is where I placed the Csla classes, butobviously for any solution that ).

As far as controllers our focus is going to be strictly onCustomerController, and OrderController.  HomeController is just thedefault one that gets created by the MVC project wizard, andAccountController is the one that takes care of security (login,changing passwords, etc).

 When it comes to views just notice that Customer Controller has oneview (List.aspx), while OrderController has no views in the Views/Orderfolder.  I will explain that part later in the UI section. 

 Source for this demo can be found at:

ExtJsDemo.zip (2.58 mb) 

ExtJsDemo.zip (2.66 mb)

 At the back end of this demo is a copy of the Northwind database (found in App_Data folder).   It is a simple screen with 3 ReadOnlyList object.  On the left you will see a Drop Down with a list of customers.  Once a Customer is selected, we load a list of Orders for that Customer.  When selected, order displays its order details in the drop down below.  

All of the actions on this screen utilize Ajax calls.  Now for the choice of Ajax framework used here.  MS Ajax as it is built is out of questions.  It was built to support web form post back/callback model, which really cannot take advantage of the MVC model.  And simply put it is not very easy to use outside web forms.  AS far as MS MVC Ajax – MS folks have just started working on it for the latest CTP 5 release, and they are years behind ExtJs, Jquery, and other libraries.

That leaves us with JQuery and ExtJs (at least fro now).  However, one good thing about MVC framework, is that is built from scratch to be easily extensible, and to play well with any of the third part tools.  You will see in some of my future posts on this demo that I utlize xUnit.net and excellent unit test framework that drives the innovations in .Net unit testing world.  Not nUnit, or MSTest. Or for the same reason choice of RhinoMocks as the Dynamic Mocking framework.  For the same purpose in the future versios of this demo we will utilize StructureMap as a Dependency Injection framework instead of MS Unity.  All of these play very well with MVC and prove how extensible it is.  But enough about that - lets mov on with our demo solution.

There are conceptual differences with the JQuery and ExtJs.  JQuery is more focused on building dynamic html with its Ajax calls to the server, and dynamically inserting modifying parts of the page in response to Ajax action.  If for example you want to render a custom modal pop-up dialog inside the page, as a result of action on the page JQuery will submit action to the server – controller, that will then render the content of the dialog back to the page.  JQuery will then insert the dialog inside the modal frame control and display it.  That is more in line with traditional Ajax development.

My choice of the ExtJs had something to do with a lot of CSLA developers coming from the Windows world.  ExtJs actually provides us with the visual components/controls, like grids, drop downs, tabs, windows, etc…  This controls utilize JSon to submit modified data to the server, and receive the content they need to render from the server.  So instead of receiving a content of the grid control, for example, as a partial html page (table element), from the controller action, ExtJs grid actually receives what is called a JSon reader, and binds it to a sortable/ customizable grid control.

That way our server MVC model; actually utilizes more of a familiar control/event model on the client and I would actually say that for Windows developers this might be even easier migration path than the web forms.
In the next post I will be talking about UI portion of this demo, provide details of how we convert Csla objects into Json stream, send it from the Controller action and then utilize it within ExtJs Drop Down and Grid controls.  This post will mostly be about server side unit testing for controller and routes.  The fourth and final post should focus on the choice of Data Access Layer pattern – repository, and its integration into Csla code.

ExtJsDemo.zip (2.66 mb)

I have received few comments on the first post, one of them being from Rocky Lhotka the creator of the Csla.Net framework.  He basically pointed to his advanced data sample (DeepData.sln available for download at www.lhotka.net). 

The idea is that if we encapsulate all of the ADO.NET constructs required to fetch/update a single table into a “Data object” and move it from the Fetch() method of Csla object (some might find this similar to Table Data Gateway pattern), then the only thing we have to mock is that Data object. 

In addition setting expectations would be lot simpler, since everything is encapsulated.  So, instead of me talking about it lets look at how that changes the Fetch method of the ProjectList class defined in PTracker sample:

private void Fetch(string nameFilter) {

     RaiseListChangedEvents = false;

     DataFactory df = new DataFactory();

     using(ProjectListData data = df.GetProjectListDataObject()) {

         SafeDataReader dr = data.GetProjectList();

         IsReadOnly = false;

         while (dr.Read()) {

             ProjectInfo info = new ProjectInfo(

               dr.GetGuid(0),

               dr.GetString(1));

               // apply filter if necessary

               if ((nameFilter.Length == 0) || (info.Name.IndexOf(nameFilter) == 0))

                 Add(info);

         }

         IsReadOnly = true;

     }

     RaiseListChangedEvents = true;

}

Code above is simpler than the original or the refactored code I had (only a single using block, and no ADO.NET dependencies) .  So lets take a look at what happened.  We stopped using the Database class (that functionality will move into our Data object – ProjectListData).  We can see 2 new objects constructed in this code: 1.       DataFactory – Factory in charge of instantiating all of the Data objects for our project 2.       ProjectListData – Data object, whose purpose is to encapsulate the ADO.NET constructs, and return a SafeDataReader back to the Ftech() method. 

It is important to note that ProjectListData implements IDisposable interface.  That way as we dispose of it, it will dispose corresponding DataReader, DbCommand and a Connection.  Hence only one using block needed here. Test are then as simple as:

[Test]

public void LoadsOne() {

     Mock mockProjectListData = MockManager.Mock(typeof (ProjectListData));

     mockProjectListData.ExpectAndReturn("GetProjectList",

         new ProjectListFetchOneDRStub().GetDataReaderStub());

     mockProjectListData.ExpectCall("Dispose");

     ProjectList item = ProjectList.GetProjectList();

     Assert.AreEqual(1,item.Count);

}  

[Test(Description = "DataReader returns 3 items but only one should be inserted, based on filter")]

public void LoadsThreeFiltersTwo() {

     Mock mockProjectListData = MockManager.Mock(typeof(ProjectListData));

     mockProjectListData.ExpectAndReturn("GetProjectList",

         new ProjectListFetchThreeDRStub().GetDataReaderStub());

     mockProjectListData.ExpectCall("Dispose");

     ProjectList item = ProjectList.GetProjectList("test");

     Assert.AreEqual(1, item.Count);

}  

As you can see mocking of the fetch process and replacing of the SafeDataReader is only couple of lines of code.  First line defines that we intend to mock ProjectList object.  Second one sets expectation that the method called GetProjectList() will be called.  Result of that call is supposed to be replaced by result of the call to  ProjectListFetchOneDRStub().GetDataReaderStub() in the first test, or the ProjectListFetchThreeDRStub().GetDataReaderStub() in the second test. 

These two methods return our stub DataReaders that contain the test data (source code for these is available in my previous post).  And that is it.  Rather simple!

At the end let me show you the code of our ProjectListData object:

public class ProjectListData : IDisposable {

     private SqlConnection _cn;

     private SqlCommand _cm;

     private SafeDataReader _data;

     private bool disposed;

     internal ProjectListData()

     {

         _cn = new SqlConnection(Database.PTrackerConnection);

         _cm = _cn.CreateCommand();

         _cm.CommandType = CommandType.StoredProcedure;

         _cm.CommandText = "getProjects";

         _data = new SafeDataReader(_cm.ExecuteReader());

     }

     public SafeDataReader GetProjectList()

     {

         return _data;

     }

     #region IDisposable Members

     public void Dispose()

     {

         Dispose(true);

         GC.SuppressFinalize(this);

     }

     protected virtual void Dispose(bool disposing)

     {

         if (!disposed) {

             if (disposing) {

                 // Dispose managed resources.

                 _data.Dispose();

                 _cm.Dispose();

                 _cn.Dispose();

             }

             // Dispose unmanaged resources

         }

         disposed = true;

     }

     #endregion

}