I would like to hear from others that may be doing something similar.

If I have a team and we are using Agile development methodologies what is the best way to use LLBLGen Pro 2.5 for this scenario:

1. Intranet Application
2. Needs to be support up to 500 users
3. Test Driven Development
4. VS 2008
5. Ajax / web 2.0 type effects for the gui
6. Separate Business Layer or direct LLBLGen generated code?
7. Adapter or Self Servicing?

I appreciate all feedback!

Wade I'm in the same situation. I returned from an agile training course and I am now working through daily examlpes of BDD/TDD/Agile (i'll call it agile from here on out) and LLBL.

since your using VS2008 and ajax you may want to consider using the MS MVC framwork which will be previewed in a few weeks.

Separate Business Layer or direct LLBLGen generated code? I debate this one too. Should LLBL just be a DAL, or should the entities be my Domain objects? for my current project they are my domain objects. I am finding that mocking (RhinoMocks) entity classes works, but i would prefer mocking entity interfaces (ICustomerEntity). One methodology i did pickup at my training was to use presentation dtos and completely shield the presenation from the domain via a service/task layer. this requires more code and complexity, but allows you to develop the gui/presentation independent of the domain/bll.

my personal preference is adapter. this also helps with unit testing. mockery.DyanmicMock<IDataAccessAdapter>(). I can now test the behavior of a repository without actually accessing a physical database. not sure if that possible with SS.

The current delima i have is truely testing a repository object. example

public class CustomerRepository : ICustomerRepository
{
     public CustomerRepository()
          : this(new DataAccessAdapter())
     {
     }

     public CustomerRepository(IDataAccessAdapter adapter)
     {
           this.adapter = adapter;
     }

     public EntityCollection<CustomerEntity> FetchAllCustomersIn(string state)
     {
          EntityCollection<CustomerEntity> listOfCustomers = new EntityCollection<CustomerEntity>();

          IRelationPredicateBucket bucket = new RelationPredicateBucket(CustomerFields.State == state);

          adapter.FetchEntityCollection(listOfCustomers, bucket);
          return listOfCustomers;
     }
}

if i want to unit test this it looks like this:

[TestFixture]
public class CustomerRepositoryTest
{
      MockyRepository mockery;
      private IDataAccessAdapter mockAdapter;

      [SetUp]
      public void Setup()
      {
            mockery = new MockRepository();
            mockAdapter = mockery.DynamicMock<IDataAccessAdapter>();
      }

      [Test]
      public void Should_be_able_to_fetch_all_customers_located_in_PA()
      {
            string pa = "PA";
            using (mockery.Record())
            {
                  mockAdapter.FetchEntityCollection(new EntityCollection<CustomerEntity>(), new RelationPredicateBucket(CustomerFields.State == pa));
                  LastCall.IgnoreArguments();
            }

            using (mockery.Playback())
            {
                  CreateSUT().FetchAllCustomersIn(pa);
            }
      }

      private ICustomerRepository CreateSUT()
      {
            return new CustomerRepository(mockAdapter);
      }
}

this works and passes. only because i ignore the arguments passed to the mockAdapter. If i remove LastCall.IgnoreArguments(); then the test will fail because the agruements passed to the mockAdapter are not the actual objects used by CustomerRepository. I could as easily passed null as the agruements. with this test i truely testing behavoir, not state. I would need an integration test to truely access the db and fetch all the customers in pa.

i haven't found a better way to handel this scenario yet. One thought would be to have a factory class return IRelationPredicateBucket. then i could mock the call to create the bucket. This would require quite a few factories through sorts, groupings, prefetches, collections.

as for testing web based gui. you could use Watin [http://watin.sourceforge.net/]. i haven't used this, but I have heard it mentioned before.

this is where I am now with agile testing.

I appreciate your feedback. It looks like you made the choice of using the Adapter model vs the Self Servicing.

What was your reasoning behind that? Do you think it takes longer to work with for an intranet application?

I have worked with the windows version of MVC on a couple of applications and moved away from it. The reasons were:

1. Too steep of learning curve for developers
2. While patterns are a good thing, doing patterns for patterns sake is not always the right answer.
3. Time to deliver business solutions is longer and the business is always waiting on IT
4. We use mostly contractors and their time to learn this costs a lot more money because I have not run into any that knew the MVC patterns and toolsets out of the box

Again thanks for the input!

i choose adapter because I liked the idea of "knowing" what my entity contains when I request it. I also figure it should reduce db hits because I'm prefetching what I need ahead of time. In some instances I need to hit 2 sql dbs, to transfer data. adapter allows for this within one set of domain objects, SS doesn't. I also like the separation of concerns. the domain is just the domain and the adapter is the gateway to the db.

i don't think it takes longer to program adapter vs SS. adapter is unit testable without requiring an actual db connection. SS maybe possible, but i haven't worked with that model. really you need to determine what your requirements are to choose the model that best fits. 1. should every developer be able to fetch any data from the db (yes = ss/adapter, no = adapter) 2. will you app require remoting/web services (yes = adapter, no = ss/adapter) 3. will your app contain tasks/services/managers to manage how domain graphs are returned. (yes = adapter, no = ss/adapter) [goes along with question 1] I'm sure there are more, but it's 10:30 on a Friday night

to your points 1. yeah it's a far cry from the M$ way. i didn't fully grasp it until after an intensive week long training boot camp with JP Boodhoo [http://www.jpboodhoo.com] 2. I'm guilty of this. I was first introduced to OOP patterns through this forum. since then I have found other resources to assist me. I'm somewhere between novice/moderate OOP skills. 3. Good/Fast/Cheap; pick two management always goes for Good & Cheap

1. will you app require remoting/web services (yes = adapter, no = ss/adapter)

Of course that is assuming you are passing the actual entities over the remoting/web services. If you are not passing the entities and instead your own interfaces or objects, then ss/adapter are both fine in this situation.