Design and Architecture

Leftyfarrell wrote:

the DALUser class doesn't really do much... so it is still worth unit testing?

// Service layer (business component, contains logic)
class UserService
{
   IDataMapper<User> _mapper;

   public UserService(IDataMapper<User> mapper)
   {
       _mapper = mapper; // Inject mapper into service
   }

   // Operations to load, save, and work with users,
   // orchestrating interations between UserDAL and User

   public User Load(int id) { //... }
   public void Save(User user) { //... }
}

// Entity layer (business object, contains data)
class User
{
   int ID { get; set; }
   // Contains user data
}

// Data Access layer
interface IDataMapper<T>
{
    T GetByID(int id);
    T Insert(T item);
    void Update(T item);
    void DeletE(T item);
}

class UserDAL: IDataMapper<User>
{
   // Implements IDataMapper for User...this COMPLETELY abstracts 
   // data access logic from the business objects and components,
   // so all they have to do is get, insert, update, and delete 
   // without caring at all how its done...exactly how it should be
}

class MockUserDAL: IDataMapper<User>
{
    // Implements a mock version of IDataMapper for User...returning canned results
}

[TestMethod]
public void Test_UserService_Load
{
    MockUserDAL userDal = new MockUserDAL();

    UserService userSvc = new UserService(userDal);

    User user = userSvc.Load(1);

    Assert.IsNotNull(user);
    Assert.AreEqual(1, user.ID);
}

Philip Laureano wrote:

so my question is, has anyone managed to do this yet?

Mark Churchill wrote:

Hrmmm I'd be assuming you are kinda boned in that case without some real trickery. Most legacy code of this kind I've seen tends to be fairly rigid - definitely no dependancy injection or even factory patterns. It sounds hard.

Mark Churchill wrote:

Possibly you could do something like post-process the compiled DAL, and replace instantiations of certain classes with your mocked instances, and then run the tests. :S

Pete O'Hanlon wrote:

Have you looked into Pex[^]? It's an interesting concept, to say the least.

paresh_joe wrote:

I want a way to apply atomicity to this.

paresh_joe wrote:

My requirement is to not to make any change in parameter list or not to provide a new method with new parameter.

paresh_joe wrote:

One way i can think of is to create a DB ptr and begin transaction just before call to FunctionOfClassB() and pass it as a parameter.