Data Access Layer - Designing Class where should responsibility of creating saving be

Question

I am designing Data Access Layer with ADO.NET 2.0 and C#, Sql Server 2005. I often fight with my brain over where to place those calls. Which way of the below i should follow for maintainable robust code.

Method 1

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}

public bool Create()
{
}

public bool Update()
{
}

public bool Delete()
{
}

}

Method 2

Public Class Company
{

public string CompanyId
{get;set;}

public string CompanyAddress
{get;set;}
}

and i would use another class like below to do the core data access. Like below

Public Class CompanyRepository
{

public Company CreateCompany(string companyId,string companyDescription)
{
}

public bool UpdateCompany(Company updateCompany)
{
}

public bool DeleteCompany(string companyId)
{
}

public List<Company> FindById(string id)
{
}


}

score 7 · Accepted Answer · answered Jan 15 '12 at 13:42

7

Go with method 2. It is not the Company class's responsibility to read/write from a data source (single responsibility principle). However, I would even go as far as creating an ICompanyRepository interface and then creating a CompanyRepository implementation for the interface. This way you can inject the ICompanyRepository into the class that needs to save/retrieve company information. It also allows easier unit testing and the ability to create a different implementation in the future (switching from a database to xml files or whatever).

answered Jan 15 '12 at 13:42

Jason Down

21,731
12
83
117

1

yup i do use ICompanyRepository to maintain/extend list of methods that Company can extend into. Just that too much code is sometimes not needed in the questions do they ;) – Deeptechtons Jan 15 '12 at 13:44
@Deeptechtons: True enough ;) – Jason Down Jan 15 '12 at 13:45
Actually it nso code- come to the current echnology, please. It is IRepository and generic and it uses a generic DAL. Anyone writing the code himself fo a standard DAL fails junior programming requirements for any of my teams. I wrote a generic DAL 10 years ago before generics where in .NET - today IQueryable is the seach interface, provided by LYNC and you write a LYNC provider. Anything else is a shame. And you write generic methods for updating and saving. – TomTom Jan 15 '12 at 14:09
@TomTom: Yes I do agree with the generic approach to the repository (why recreate the same code every project?). Never used LYNC (or heard of it until today). Time to learn something new! – Jason Down Jan 15 '12 at 14:21
@TomTom: Although I should add that trying to force everything into a one-size-fits-all generic repository is not *always* the approach to take. It can lead to leaky abstractions when you don't require everything exposed by the interface (or when you must prevent certain methods (e.g. when you don't want to allow saving/updating because the data source should only be readonly). Use a generic repository when it makes sense (which is *usually*). – Jason Down Jan 15 '12 at 15:13
@JasonDown accepted as answer. Although i didn't get much out of TomTom comments. Does he mean instead writing Interface for each repository i should create something generic? – Deeptechtons Jan 15 '12 at 15:46
@Deeptechtons: That is part of what he was saying. Here is a link links to explain it in more detail: http://forums.asp.net/t/1629771.aspx/1 And here is an argument against it (without making some slight modifications): http://richarddingwall.name/2009/01/19/irepositoryt-one-size-does-not-fit-all/ – Jason Down Jan 15 '12 at 16:36
Actually I say that if you sit down and do that you have NO sense in being in programming - much like a cook having problems making eggs has no future in a professional kitchen. – TomTom Jan 15 '12 at 16:37
@Deeptechtons: Here is information about LYNC: http://en.wikipedia.org/wiki/Microsoft_Lync – Jason Down Jan 15 '12 at 16:37
@Jason Down: Actually - sorry. Your link is either outdated or witte nby an idiot. Next time I see a repository with "GetAll" or "GetById" the person gets fired and i sleap his face for incompetence. LINQ solved this problem for years now. – TomTom Jan 15 '12 at 16:39
@Jason Down: AND - your link to Wikipedia is comical. Really. LINQ != LYNC. LINQ = Language Integrated Query. LYNC = Success to Microsoft Office Communication Server, basically a communication system. Totally unrelated link. – TomTom Jan 15 '12 at 16:41
2

@TomTom: You're the one who wrote LYNC, not LINQ (in your first comment). I know what LINQ is. I just provided a link to LYNC because I don't know what it is and have never heard of it you brought it up (and confused me and obviously the op). Why don't you stop being a jerk and be useful. Provide a better answer instead of being immature. – Jason Down Jan 15 '12 at 16:48
Yeah, but i did not link wikipedia here ;) – TomTom Jan 15 '12 at 19:09

score 2 · Answer 2 · answered Jan 15 '12 at 13:38

2

If you follow the principle of separation of concerns, you will go with your method 2.

Having different responsibilities in different classes does help with creating testable, maintainable code.

This also produces smaller, more cohesive classes that are easier to write, reason about and check for correctness.

As a note, you can use an ORM instead of hand crafting your data access layer.

answered Jan 15 '12 at 13:38

Oded

489,969
99
883
1,009

thank you for that answer, i don't have much experience in the industry to arrive at a decision that's the reason i put this on SO. Could you explain more on how the method2 will help me other than providing `SOP` – Deeptechtons Jan 15 '12 at 13:42
@Deeptechtons - I have added some more detail. – Oded Jan 15 '12 at 13:43
we could use a ORM we are investigation NHIBERNATE for next project, but now for current project i got no choice :) thanks – Deeptechtons Jan 15 '12 at 13:46

score 1 · Answer 3 · answered Jan 15 '12 at 13:41

I would stand for second choice, cause

first you create your data holder
after crate your operational unit

So in this case you separate the data from functions that operate on them, making UnitTesting notably easier and destributing the responsibilities between different domains of your code, with, possibly, easy bugs localizations.

Data Access Layer - Designing Class where should responsibility of creating saving be

Method 1

Method 2

3 Answers3