Usage of Single Responsibility Principle with bank account services implementation

I had code that violated the Single Responsibility Principle in a question on Stack Overflow.

In order to overcome that problem, I changed the code as follows.

• Is this a good practice in order to overcome the problem?

• Is this a pattern?

• Is there a better way?

• Does it satisfy the Unit Of Work pattern using LINQ-to-SQL?

namespace DomainObjectsForBank
{
    public interface IBankAccount
    {
        int BankAccountID { get; set; }
        string AccountStatus { get; set; }
        void FreezeAccount();
        RepositoryLayer.IRepository AccountRepository { get; set; }
    }

    public class FixedBankAccount : IBankAccount
    {
        public int BankAccountID { get; set; }
        public string AccountStatus { get; set; }

        public void FreezeAccount()
        {
            //ChangeAccountStatus();
            AccountStatus = "Frozen";
        }

        //private void ChangeAccountStatus()
        //{
        //    AccountStatus = "Frozen";
        //    RepositoryLayer.BankAccount repositoryBankAccEntity = new RepositoryLayer.BankAccount();
        //    repositoryBankAccEntity.BankAccountID = this.BankAccountID;
        //    accountRepository.UpdateChangesByAttach(repositoryBankAccEntity);
        //    repositoryBankAccEntity.Status = "Frozen";
        //    accountRepository.SubmitChanges();
        //}

        private RepositoryLayer.IRepository accountRepository;
        public RepositoryLayer.IRepository AccountRepository
        {
            get
            {
                return accountRepository;
            }
            set
            {
                accountRepository = value;
            }
        }
    }
}

```
using System.Collections.Generic;
using System;

namespace ApplicationServiceForBank
{
public class BankAccountService
{
RepositoryLayer.IRepository accountRepository;
ApplicationServiceForBank.IBankAccountFactory bankFactory;

public BankAccountService(RepositoryLayer.IRepos

I'm not sure about some of your questions, but a few ideas I have are:

• Could you make the the account status and even account types an

enumeration? I tend to try and err on the use of enumerations over string literals. I believe the latest version of Linq to SQL supports this?

• Why do you need to expose the repository on your IBankAccount interface. Why would the interface even care about a repository? I think this is better being supplied to any concrete classes via it's constructor? It would also make unit testing easier I would think.

• I personally wouldn't pass in the whole BankAccount object into the factory method. It only needs the account type so I would pass in that. Probably I would look at using a switch or if else in that factory method as well and throwing an exception if you can't create it (depends on your requirements of this method).

Just a few thoughts.

StackExchange Code Review Q#13148, answer score: 3