Getting back into .Net, Current Data access models?

m1nder

Hi,

I have been out of the .Net loop for two years. I left it at 2.0. Getting back into it now and I'm wondering where to start ?

I'm interested in the norm / popular / most common practices with regard to data access and n tier construction. Where do I start studying?

I used to use n tier like this
Sql Server 2000/2005
Stored procs/functions/cursors etc
.Net 2.0 Business logic
Application Code
UI

So, if I'm heading back into the job market now, what should I be studying? Can anyone recommend a good intro to 3.0 / 4.0 data access, practices etc? What are the key .Net technologies in play these days. How are .Net programmers building n tier these days?

Many thanks

John_Mc

m1nder wrote: »

Hi,

I have been out of the .Net loop for two years. I left it at 2.0. Getting back into it now and I'm wondering where to start ?

I'm interested in the norm / popular / most common practices with regard to data access and n tier construction. Where do I start studying?

I used to use n tier like this
Sql Server 2000/2005
Stored procs/functions/cursors etc
.Net 2.0 Business logic
Application Code
UI

So, if I'm heading back into the job market now, what should I be studying? Can anyone recommend a good intro to 3.0 / 4.0 data access, practices etc? What are the key .Net technologies in play these days. How are .Net programmers building n tier these days?

Many thanks

It's all about Object-Relational Mapping these days. Writing SQL is going to be a thing of the past for application developers in the not too distant future because of it.

It's absolutely fantastic because you can very easily model your database as objects in your code, or create your objects first and then have the database schema created automatically for you. Inserting a new object to the database is as simple as "DbContext.Cars.Add(newCar); SaveChanges();"

NHibernate is probably the most common one because it's mature and tried and tested by the industry. It is very feature rich and well supported.

Entity Framework 4.1 is the latest and greatest from Microsoft at the moment. The update from 4.0 to 4.1 introduced a lot of features that calmed the critics. So if be sure to differentiate when looking it up.

I'm personally finding E.F better to work with because there's less setting up involved.

The most popular pattern is the Repository Pattern. A lot of people try to make it Generic, but I've found this hard to do properly because there's always at least a few domain specific functions in every application.

You can use the Repository pattern, which both NHibernate and E.F enforce by default, in conjunction with the Unit of Work pattern to handle transaction errors and rollbacks.

Another thing you're going to have to lookup is LINQ. It's made everything so much easier

m1nder

Thank you very much John Mc, great reply.

When you say "NHibernate is probably the most common one", what do you mean? most common what?

Also MS Entity Framework, is that part and parcel of Visual Studio? I have VS 2010 etc.

I remember seeing 3.0 coming out and feeling bamboozled by all the new data access features. I could not get my head around the taxonomy of it. But if I might hazard a guess....Are we talking about a data access context designer? Dragging and Dropping tables / stored procs etc onto a window. This writes the c# class code in the background and allows me to consume that. Am I thinking correctly here?

I did mess around with LINQ. Am I right in thinking its a baby wrapper for sql? as in the pure sql is still generated in the background but LINQ is designed to simplify?

Finally (and Im a bit embarrassed by this), whats a pattern?

Many thanks

k.p.h

Object-Relational Mapping :eek:

Swiftly moving along

m1nder

k.p.h wrote: »

Object-Relational Mapping :eek:

Swiftly moving along

what does that mean?

k.p.h

Sorry m1nder, just messing. Complete beginner and I just read the wiki page hence the :eek:

Sounds useful though

Hibernate is concerned with helping your application to achieve persistence. So what is persistence? Persistence simply means that we would like our application's data to outlive the applications process. In Java terms, we would like the state of (some of) our objects to live beyond the scope of the JVM so that the same state is available later.

Giblet

You can use a generic repository with a common impl class which other impl classes extend from. Also, SQL will never be a thing of the past, as NHibernate etc leverage it, and do a bad job with scaling. I think it gives up the ghost in extremely large domains or complex ones. I use stored procedures and my own simple Table -> Object mapper when reading them.

Writing in a repository pattern is a good idea because you shouldn't care what's driving the DAL from the service. Just call a repository function and make sure it can provide the contract in any way possible. Combined with dependency injection and inversion of control, you'll have a very capable app.

stevenmu

If you're interested in ASP.Net look at MVC, and possibly LightSwitch.


SharePoint is pretty in demand at the moment, but that's a whole other area.

m1nder

Hoping to get past the academic and the abstract. If anyone has any practical examples I'd really appreciate hearing. What DB are you using? What and how did you code? What tools did you use?

Many thanks

Giblet

SQL Server 2008, wrote a basic SQLConnection class, fire Datareaders through my custom ORM written using IL emit to attach dynamic methods to the business entities.

This feeds into a repository which through an aggregate root (or parent) handles the population of subchildren (if available) through lazy loading (if necessary).

A business logic layer then passes information from the view to the repository to pull back fully formed objects, does business logicy stuff on the data, and returns to view. I have an MVC layer for handling view stuff. My controllers basically talk to business logic layer using the data passed to them, and pulls out a viewmodel to display, using handy stuff like

public ActionResult Promotions(ICategory category)
{
    var promoProducts = ProductService.GetAllOnPromotionByCategory(category);
    return View(promoProducts);
}

Uses IOC container and Dependency Injection to resolve my common interfaces (such as ICategory, or the business logic layer, or repos etc) I can chop and change any layer to to something else, or change the productservice or productrepo to provide test data or run test cases.

Easy enough to come up with a practical example if you need it.

m1nder

Giblet wrote: »

SQL Server 2008, wrote a basic SQLConnection class, fire Datareaders through my custom ORM written using IL emit to attach dynamic methods to the business entities.

This feeds into a repository which through an aggregate root (or parent) handles the population of subchildren (if available) through lazy loading (if necessary).

A business logic layer then passes information from the view to the repository to pull back fully formed objects, does business logicy stuff on the data, and returns to view. I have an MVC layer for handling view stuff. My controllers basically talk to business logic layer using the data passed to them, and pulls out a viewmodel to display, using handy stuff like

public ActionResult Promotions(ICategory category)
{
    var promoProducts = ProductService.GetAllOnPromotionByCategory(category);
    return View(promoProducts);
}

Uses IOC container and Dependency Injection to resolve my common interfaces (such as ICategory, or the business logic layer, or repos etc) I can chop and change any layer to to something else, or change the productservice or productrepo to provide test data or run test cases.

Easy enough to come up with a practical example if you need it.

I ran this through google translate, still cant understand it.

Giblet

Download VS2011 Developer Preview, and let's get started

mewso

m1nder just read up on domain driven design. You'll see most of these patterns/terms discussed. Using object relational mappers is all about mapping objects to your database. At the end of the day a good expressive model of your system/domain will not fit simply into a relationship database so along come orms to do it for you. I have used nHibernate but would agree that the latest entity framework is very good. I would say though that unless you have a complex system with a complex model (objects) then you don't need to go diving straight for the orm and could simply use an active record system like Castle or Subsonic. In any case you can use an existing orm or build your own like Giblet has but it's all about persisting your objects in your database.

Looks like cqrs is going to be the next big thing from what I can see. If it is ORMs may not be as critical anymore, even possibly detrimental in some cases.

m1nder

Folks. While I am very grateful for the replies, I am finding this thread way too abstract and academic. It is actually counter-intuitive to me.

What (in respect of a database) is a domain?

So NHibernate is an ORM. Is it a plugin for Visual Studio? Is it actually apiece of software or just an abstract practice model?

MS Entity Framework, is that part and parcel of Visual Studio? I have VS 2010 etc.

Lets try and simplify this.
Id someone asked you to create an inhouse app to record and maintain customers/orders/products etc. How would you go about this (in english please)?

Many thanks

Procasinator

m1nder wrote: »

I ran this through google translate, still cant understand it.

Just break it down and use Google.

Giblet wrote: »

SQL Server 2008, wrote a basic SQLConnection class, fire Datareaders through my custom ORM written using IL emit to attach dynamic methods to the business entities.

He is using Microsoft SQL Server 2008.

DataReaders read data :P. Read about 'em here: http://msdn.microsoft.com/en-us/library/ms254509(v=vs.80).aspx

ORM means object-relational mapping. Which means an object(s) in your .NET code are mapped to you database entities (i.e. tables and columns).

The next bit is a bit more complicated. It a nutshell, it generating the appropriate code to accomplish a lot the mapping between the objects and the database. For instance, when you get you tuple back from for a Person ("John", "Doe", 49) the act of going:

Person person = new Person();
person.FirstName = dataReader.getString(0);
person.LastName = dataReader.getString(1);
person.Age = dataReader.getInt32(2);

Is quite repetitive. Because the ORM is informed of the mappings (with say XML configuration for example) it can generate a lot of this repetitive code for you.

Giblet wrote: »

This feeds into a repository which through an aggregate root (or parent) handles the population of subchildren (if available) through lazy loading (if necessary).

Might have interpreted this wrong, but I would imagine this is to handle relations. For instance, a person might have pets. To look at a persons pets, we would say use person.Pets, where the property Pets is a collection of the Person class.

Of course, loading this data from DB is a waste of effort unless we request the Pets property. This is called lazy-loading - Pets won't be assigned anything until the first read, where it will then be executed.

Giblet wrote: »

A business logic layer then passes information from the view to the repository to pull back fully formed objects, does business logicy stuff on the data, and returns to view. I have an MVC layer for handling view stuff. My controllers basically talk to business logic layer using the data passed to them, and pulls out a viewmodel to display, using handy stuff like

public ActionResult Promotions(ICategory category)
{
    var promoProducts = ProductService.GetAllOnPromotionByCategory(category);
    return View(promoProducts);
}

Uses IOC container and Dependency Injection to resolve my common interfaces (such as ICategory, or the business logic layer, or repos etc) I can chop and change any layer to to something else, or change the productservice or productrepo to provide test data or run test cases.

Easy enough to come up with a practical example if you need it.

Business logic layer and MVC are related here. Model is data access and persistence,), Controller handles communication between the Model and View and View is presentation. Business logic usually belongs with the Model layer (though some might classify it as an individual layer). You might see the business logic leak into the Controller or even the View from time to time, but generally, the architecture is here to separate concerns and benefits maintenance and adaptability.

IOC container = Inversion of Control. In simple terms, it's separating out general code and problem specific code and wiring between it. It aim is really to allow changing problem specific code without impacting other code and also to build up the individual components quick. Dependency injection is the common way to achieve this, which pretty much provides the dependant entities to the code via configuration - in code example, by passing in the an object that implements ICategory to the Promotions method. <--- I don't know if that made sense.

It's too late in a Friday afternoon to attempt explaining this stuff (I almost stopped, and I probably should have), but most of it isn't really that complicated. It's the tendency to use TLAs and rigid language that slows the understanding of these patterns and techniques. That, and often their utility only become apparent in sizeable systems where all the available examples are in trivial and small systems.

m1nder

Procasinator

Great stuff and many thanks. You lost me a little in the last paragraphs but it was a big help. I think I'm worrying too much about this awful academic language that consumes the dev world these days. Its like a race to the bottom to see who can out-abstract the next. I understand the need for the underlying practices totally though. Its the underlying practices that have become almost invisible at this level.

I'm gonna start at a simpler level somewhere. Need to get to the nitty gritty faster without the abstraction. Need to see practical examples and to eb able to get my head around the taxonomy.

Many thanks to everyone for their help

mewso

m1nder wrote: »

What (in respect of a database) is a domain?

Domain as in business domain. This is essentially what makes up your business and how it is represented in a system using objects. This is then your domain model which would be a separate class project in your solution containing the relevant objects (Customer, Product, Order etc.) In this solution you would normally define repository interfaces that specify what functionality you want from your repository:-

public interface ICustomerRepository {
    Customer GetById(int Id);
    //etc.
}

Think of your repository as the data access project in your solution. Classes in the repository project will implement the interface defined in your domain model with actual data access code

m1nder wrote: »

So NHibernate is an ORM. Is it a plugin for Visual Studio? Is it actually apiece of software or just an abstract practice model?

MS Entity Framework, is that part and parcel of Visual Studio? I have VS 2010 etc.

NHhibernate is a framework written in .net. You download it, reference the relevant assemblies and then you can set it up by using mapping files or code to tell it what objects are in your domain model. i.e what properties in your Customer object, for example, match what columns in your table. The power of an ORM is that you also tell it how to map collection property, say Customer.Orders, how you want it loaded (lazy as explained or eager/immediately). You can then create a new repository project in your solution referencing nhibernate and implement those interfaces from the domain project with code to return objects, lists of object, insert/update/delete etc.

m1nder wrote: »

Lets try and simplify this.
Id someone asked you to create an inhouse app to record and maintain customers/orders/products etc. How would you go about this (in english please)?

Many thanks

Assuming you have fully discussed the project details with the client (called the domain expert in domain driven design terms) and agreed on the spec/language and so on then I would decide what methodologies to use usually involving:-

BDD - Behavioural Driven Design: I like BDD because it takes the top down approach from user interface down so you can prototype you UI and use that to drive where your app goes.

TDD - Test Driven Design: Alongside BDD this is something that took a while to win me over but I wouldn't do it any other way. Using unit tests to drive your development is the way to go.

DDD - Domain Driven Design: There are so many facets to DDD that I couldn't go into it here but it shapes your approach in a way that makes you create a model that is not concerned about the database purely about correctly modelling the system/business domain. I mention this because it's the fundamental change I made going from creating a db and tables then writing my code to simply creating a series of objects that mimic the way a business works. The mapping to a database comes later and is why ORMs are so powerful. They free you to concentrate on the modelling. Here is where you will develop you Customer, Product, Order objects etc. These objects are completely independent of any data access code.

After that comes patterns and coding best practices. This is where you will use Repository and Unit of Work, IoC, SOLID

This is a big area with a lot of strong opinions and is constantly changing. I would highly recommend watching the storefront series of videos to get a good idea of whats involved - http://www.asp.net/mvc/videos/aspnet-mvc-storefront-starter-kit.

mewso

Forgot to answer your question about Entity Framework. Entity framework works along similar lines to nhibernate but has taken a while to approach the same kind of functionality. It's getting there. I think there is a version with VS2010 but not the latest which would more closely resemble a proper ORM. The one absolute necessity with VS2010 is to install the Nuget add-in. You can instantly add these frameworks to a project with nuget. Nuget lets you browse this stuff, downloads it and references the assemblies needed, even adds configuration and so on where needed. You can instantly install nhibernate or entity framework from it's package browser.

m1nder

mewso

God bless you. That was so helpful

stevenmu

This kind of stuff always seems really complicated until you try an example or two, sometimes the easiest way to learn is to just dive right in and try.

To start at the basics, I'd suggest picking either LINQ (to SQL) or MVC and starting with them. They're both kinda different to what you where probably doing in .Net 2, but reasonably straightforward to pick up on their own, and compliment each other well too. And the other stuff is in some ways just taking the concepts they use to a more advanced level.

httpete

Hey m1nder, look at this particulare series of tutorial videos on entity framework -

https://www.youtube.com/watch?v=BS6IKdUd2V8

Goes through the entire thing explaining everything. In an hour's time you will be fully up and running with it and realise what it actually is and how useful it is. I was in the same boat as yourself until I watched these videos. Books and tutorials on the net, by their nature, make it sound way more complicated to use and understand.

EF can basically generate c# classes for you straight from a given database and it's tables. It can then automatically handle addition/deleting/editing rows using simple methods without writing any SQL. Its supposed to make data access easier and once you watch those videos you will see that it takes away all the messing about with SQL and makes handling data piece of piss.

Videos are the way to go for getting up to speed with any aspect of development, they accelerate the learning process way beyond the speed you can pick stuff up from text.

Giblet

m1nder wrote: »

Procasinator

Great stuff and many thanks. You lost me a little in the last paragraphs but it was a big help. I think I'm worrying too much about this awful academic language that consumes the dev world these days. Its like a race to the bottom to see who can out-abstract the next. I understand the need for the underlying practices totally though. Its the underlying practices that have become almost invisible at this level.

I'm gonna start at a simpler level somewhere. Need to get to the nitty gritty faster without the abstraction. Need to see practical examples and to eb able to get my head around the taxonomy.

Many thanks to everyone for their help

I'd say, create a basic MVC app, and do some basic crud stuff. Then swap out aspects or improve as you learn more.

Try creating a blog or something concrete.

Post your source here too! And I can try show you the why about any stuff I've mentioned. I won't be too abstract, I promise!

Download Visual Studio -> Create new MVC3 project and setup a database and create a table. Use any method you'd like to pull data out and have an object to hold it, then using a controller, access the data and push it to a view. There should be a ton of MVC guides to help you get that far.

Giblet

You got most of it Procrastinator, but I have the business logic in a separate project, and a interface defines the basic functionality for it in the controller. So I implement the interface in another project, and inject it into the controllers. I can swap out the business logic at any time to change how those services work.
I don't use anything concrete in my MVC project.

Also, with repositories, an aggregate root basically describes the following.

I have a parent (Let's say a Category), and that has some child objects (Products), and each product also has some child objects (Attributes).

Then in my CategoryRepository, if I call a category, I should have the entire hierarchy available without having to get the children separately, as each repository only deals with the root So if I go
var cat = CategoryRepository.GetCategory(1);
I should then be able to go
cat.Products[0].Attributes[1].Value (if these were available)
Without having to go
cat.Products = GetProducts(1);

Or whatever.

If I needed to JUST get products, then I have a ProductRepository to deal with that, but they're separate.

Now, the issue here, is that grabbing the entire hierarchy is difficult, and often slow. So that's why in the repo, I could setup some lazy loading that is called when I access the child objects.

The repo does all the work about how the objects are accessed, and my ICategory object looks like this

int CategoryId { get; set; }
string CategoryName { get; set; }
List<IProducts> Products { get; set; }

It doesn't know or care about anything functional about how it's accessed, it's as simple as can be.

Sorry for adding more stuff there OP, don't distract yourself just yet.