×
Get in touch

Get in touch with Binary

Binary Studio website uses cookies to enhance your browsing experience. By continuing to use our site, you agree to our Privacy Policy and use of cookies.

Learn more more arrow
Agree
Binary Studio 05.02.2010

.NET development. Adapter Data Class


In this article various ways of dealing with data in C# application necessary for achieving the best quality of code compliance are shown. You'll also find a couple of thoughts on application structure.

Hello, inquisitive reader. Today you will go with me to the world of programming on the .Net platform, and specifically I would like to show you how the application may be implemented to access data (the way I do it lately).

Microsoft Entity Framework, NUnit, ASP.Net MVC

I program using C# language, and this stipulates considered below technologies, libraries and environment, such as: Microsoft Entity Framework, NUnit, ASP.Net MVC, etc. Experience, intuition and common sense dictate a set of rules, which I always try to follow during development, among them – one has to follow principles of DDD (domain-driven design). Regardless of what type of applications we have to do (website, desktop application, service), it is almost always true that behind the scenes we work with a database, and a set of classes which describe the subject area of application - we call them a model. Business logic deals with instances of model classes. As a link between database one hand and a model on another an ORM (object-relational mapping) system can be considered. Here, by following fashionable trends, my choice almost always falls on Microsoft Entity Framework. Bitter experience suggests that it is very undesirable to use classes, automatically generated via Entity Framework, for a model. The reason for this lies primarily in the very title of "auto-generated classes" - after changing the database structure, they will not avoid change themselves. The key to success is that meters should be developed without a regard to the database structure, and the link between the model and automatically generated ORM classes needs to be implemented on its own. My approach for this is writing an adapter class (I usually call it DataAdapter).

Consider the basic structure of cap-class DataAdapter.

I will refrain from comments and reservations about the completeness of the provided code, assuming that the reader has got some programming experience - in fact the class is written following an Adapter design pattern (see Design patterns) with all the consequences. The immediate fillings of an adapter are:

  • Private methods – helpers,
  • CRUD-methods for working with classes of models.

And the best quality of code compliance is achieved via template method signatures, which will be discussed in detail below. The attempt to provide basic interfaces and abstract classes was not done yet, however it is clear that some repetitive patterns present in adapter’s structure. When I speak about code quality, I mean primarily two basic principles:

  • DRY ( «don't repeat yourself») - fragments of code should not overlap;
  • Keep it simple - simplicity of code is encouraged.

Below goes a code samples with comments. For the easiness I call instances of automatically generated via ORM-system classes ORM-objects.

Private helper methods.

Convert ORM-object into the model object.

Getting ORM-object from the database by an identifier.

Converting an model object into the ORM-object, and adding it into the database.

CRUD-methods.

Obtain model object from repository by its identifier. The essence of the method is sequencive call of two private helper methods.

Add a model object into the repository.

Update model object in the repository.

In the simplest case method looks like this:

However, more interesting situation is when complex object is being updated and this entails updating / addition / deletion of his sub objects. Here private helper methods with their convenient signature come to assistance:

The attentive reader must have noticed that while describing CRUD-methods I have used term "repository", in contrast to the description of private helper methods, where I have used term database. I won't explain the nuances of this moment, expecting sufficient knowledge in those reading these lines, paying attention only on the stated differences in notions.

As you can see everything is pretty simple. As I mentioned at the outset, it seems necessary and quite feasible to me to go into this direction further - to provide interfaces, abstract base classes and templates.

See you!

 

Eugene T,
.NET developer, Binary Studio.