Simple Data Access Layer


Answers

Other individuals and organizations have spent months or years developing their own ORMs and technologies -- many of which you listed -- and many are free to use. You should devote your resources toward your core application logic instead of trying to build another whole beast called ORM. There are enough offerings out there to satisfy all kinds of applications.

You said you've never been involved in building your down DAL. It's a classic starting error to try to roll your own resulting ORM (as far as time and resources, not necessarily knowledge), for those reasons stated above. If you think some of the existing offerings seem overkill, just wait until you get into the intricacies of building your own.

However if you want to compete in the ORM market and that IS your product, then go right ahead. That's my 2 cents.

Edit: If you have concerns about being bound to a certain ORM product or offering in your project, you can simply hide away whatever software you choose behind an interface and swap in other ORMs as needed...

public interface IBusinessDataOperations {
   // hides any ORM of choice
}

And if someday you have some free cycles and want to build your own ORM, even after trying other products, you can just slip it in behind this interface too.

Question

Can anyone suggest a simple Data Access Layer (C# .NET)? Not keen on using the Microsoft Application Data Access block, seems very bloated and overkill. Also don't want to use LINQ to SQL for various reasons. I want to build upon this and create our own in-house ORM, again for various reasons. In the past I've always had the Data Access Layer already built so was never involved in building....




POCO vs DTO

A POCO follows the rules of OOP. It should (but doesn't have to) have state and behavior. POCO comes from POJO, coined by Martin Fowler [anecdote here]. He used the term POJO as a way to make it more sexy to reject the framework heavy EJB implementations. POCO should be used in the same context in .Net. Don't let frameworks dictate your object's design.

A DTO's only purpose is to transfer state, and should have no behavior. See Martin Fowler's explanation of a DTO for an example of the use of this pattern.

Here's the difference: POCO describes an approach to programming (good old fashioned object oriented programming), where DTO is a pattern that is used to "transfer data" using objects.

While you can treat POCOs like DTOs, you run the risk of creating an anemic domain model if you do so. Additionally, there's a mismatch in structure, since DTOs should be designed to transfer data, not to represent the true structure of the business domain. The result of this is that DTOs tend to be more flat than your actual domain.

In a domain of any reasonable complexity, you're almost always better off creating separate domain POCOs and translating them to DTOs. DDD (domain driven design) defines the anti-corruption layer (another link here, but best thing to do is buy the book), which is a good structure that makes the segregation clear.




POCO is simply an object that does not take a dependency on an external framework. It is PLAIN.

Whether a POCO has behaviour or not is immaterial.

A DTO maybe POCO as may a domain object (which would typically be rich in behaviour)

Typically DTOs are more likely to take dependencies on external frameworks (eg attributes) for serialisation purposes as typically they exit at the boundary of a system.

In typical Onion style architectures (often used within a broadly DDD approach) the domain layer is placed at the centre and so its objects should not at this point have dependencies outside of that layer.




Links



Tags