Databases
StackOverflow2013
Postsdbo
PORefactoring code to avoid anti-pattern
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PORefactoring code to avoid anti-pattern
    primarykey
    data
    text
    <p>I have a BusinessLayer project which has the following code. The domain object is FixedBankAccount (which implements IBankAccount).</p> <ol> <li><p>The repository is made as a public property of the domain object and is made as an interface member. <strong>How to refactor it so that repository will not be an interface member</strong>?</p></li> <li><p>The domain object (FixedBankAccount) makes use of the repository directly to store the data. Is this a violation of Single Responsibility Principle? How to correct it?</p></li> </ol> <p>Note: The repository pattern is implemented using LINQ to SQL.</p> <p><strong>EDIT</strong></p> <p>Is the code given in the following a better approach? <a href="https://codereview.stackexchange.com/questions/13148/is-it-good-code-to-satisfy-single-responsibility-principle">https://codereview.stackexchange.com/questions/13148/is-it-good-code-to-satisfy-single-responsibility-principle</a></p> <p><strong>CODE</strong></p> <pre><code>public interface IBankAccount { RepositoryLayer.IRepository&lt;RepositoryLayer.BankAccount&gt; AccountRepository { get; set; } int BankAccountID { get; set; } void FreezeAccount(); } </code></pre> <p><br></p> <pre><code>public class FixedBankAccount : IBankAccount { private RepositoryLayer.IRepository&lt;RepositoryLayer.BankAccount&gt; accountRepository; public RepositoryLayer.IRepository&lt;RepositoryLayer.BankAccount&gt; AccountRepository { get { return accountRepository; } set { accountRepository = value; } } public int BankAccountID { get; set; } public void FreezeAccount() { ChangeAccountStatus(); } private void SendEmail() { } private void ChangeAccountStatus() { RepositoryLayer.BankAccount bankAccEntity = new RepositoryLayer.BankAccount(); bankAccEntity.BankAccountID = this.BankAccountID; accountRepository.UpdateChangesByAttach(bankAccEntity); bankAccEntity.Status = "Frozen"; accountRepository.SubmitChanges(); } } </code></pre> <p><br></p> <pre><code>public class BankAccountService { RepositoryLayer.IRepository&lt;RepositoryLayer.BankAccount&gt; accountRepository; ApplicationServiceForBank.IBankAccountFactory bankFactory; public BankAccountService(RepositoryLayer.IRepository&lt;RepositoryLayer.BankAccount&gt; repo, IBankAccountFactory bankFact) { accountRepository = repo; bankFactory = bankFact; } public void FreezeAllAccountsForUser(int userId) { IEnumerable&lt;RepositoryLayer.BankAccount&gt; accountsForUser = accountRepository.FindAll(p =&gt; p.BankUser.UserID == userId); foreach (RepositoryLayer.BankAccount repositroyAccount in accountsForUser) { DomainObjectsForBank.IBankAccount acc = null; acc = bankFactory.CreateAccount(repositroyAccount); if (acc != null) { acc.BankAccountID = repositroyAccount.BankAccountID; acc.accountRepository = this.accountRepository; acc.FreezeAccount(); } } } } </code></pre> <p><br></p> <pre><code>public interface IBankAccountFactory { DomainObjectsForBank.IBankAccount CreateAccount(RepositoryLayer.BankAccount repositroyAccount); } </code></pre> <p><br></p> <pre><code>public class MySimpleBankAccountFactory : IBankAccountFactory { public DomainObjectsForBank.IBankAccount CreateAccount(RepositoryLayer.BankAccount repositroyAccount) { DomainObjectsForBank.IBankAccount acc = null; if (String.Equals(repositroyAccount.AccountType, "Fixed")) { acc = new DomainObjectsForBank.FixedBankAccount(); } if (String.Equals(repositroyAccount.AccountType, "Savings")) { acc = new DomainObjectsForBank.SavingsBankAccount(); } return acc; } } </code></pre> <p><br></p> <p>READING: </p> <ol> <li><p><a href="https://stackoverflow.com/questions/2241133/ddd-entity-state-transition">DDD - Entity state transition</a></p></li> <li><p><a href="https://codereview.stackexchange.com/questions/13148/is-it-good-code-to-satisfy-single-responsibility-principle">https://codereview.stackexchange.com/questions/13148/is-it-good-code-to-satisfy-single-responsibility-principle</a></p></li> <li><p><a href="https://stackoverflow.com/questions/4412059/using-the-single-responsibility-principle-forces-my-containers-to-have-public?rq=1">Using the &quot;Single Responsibility Principle&quot; forces my containers to have public setters</a></p></li> <li><p><a href="https://softwareengineering.stackexchange.com/questions/150760/single-responsibility-principle-how-can-i-avoid-code-fragmentation">https://softwareengineering.stackexchange.com/questions/150760/single-responsibility-principle-how-can-i-avoid-code-fragmentation</a></p></li> </ol>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USLijo
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. PORefactoring code to avoid anti-pattern
      1. This table or related slice is empty.
      1. VTApproveEditSuggestion
    1. COMaybe Code-review it a better place?
      singulars
      1. PORefactoring code to avoid anti-pattern
      1. USgdoron
    2. COFWIW in most dependency injection scenarios, the Repository would have to be made public on the *class* for DI to work (i.e. at face value violating encapsulation), however, dependencies (like Repository) would NOT need be added to the Interface. All access to the class instance will be through the interface and hence the fact that the Repository class property is public is a non-event. However, since you are using factory method for instantiation, public dependencies aren't needed.
      singulars
      1. PORefactoring code to avoid anti-pattern
      1. USStuartLC
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload