CODEWITHSUNDEEP
.netdesign-patternsdatabase-designdata-access-layer
cloudguy
cloudguy

Reputation: 25

Design DAL/DataSet/Business Objects

I am currently designing an application (.Net WinForms) that needs to access a database (SQL Server).

Using the datasource wizard, Visual Studio automatically creates the dataset, tables and classes for rows:

For example if I have the Customers table the wizard will create “CustomersRow” class that inherits from Global.System.Data.DataRow with the corresponding fields as properties.

In my application I need to implement other methods and attributes for the Customers class.

How to deal with these generated classes, modify them by adding methods.. or ignoring them and implement my own business classes?

A second question:

How to populate my objects (eg list of customers?)

Do you suggest using datatables / dataset and their methods or build my own data access layer and I meet the client list (of customers)?

I found some patterns when searching the net but it is not precise.

Thanks

Upvotes: 1

Views: 667

Answers (4)

Davide Piras
Davide Piras

Reputation: 44595

look at my other answer here:

MVC3 and Entity Framework

basically MVC, WinForms, WPF or whatever you have as Presentation Layer the layering I described there is still valid.

the real shape of your Data Access Layer could change internally depending on what you use in there, like NHibernate, Entity Framework, no ORM at all but raw/pure SQL access, whatever you do is limited and contained in there and you will have great life if you abstract from that at the most and all your other layers are designed to be independent from it.

Upvotes: 0

Jordan Parmer
Jordan Parmer

Reputation: 37164

When it comes to layers and tiers, keep it simple. Some developers get very academic when it comes to business tiers but all they are doing is adding unnecessary complexity (beware architecture astronauts). So my first advice is to keep it simple and easy to maintain for your particular application.

The goal is to hit a balance between maintenance complexity and flexibility. You want your app to have the flexibility to grow without requiring a lot of changes but at the same time, you want to be able to have an application that is simple to understand.

Having at least one layer between your persistence and client is a good thing. This gives you the flexibility of putting a domain and/or service in-between the client and the database. I wouldn't go beyond this unless you are solving a specific problem.

As for loading from your persistence, you can use partial classes to extend the generated persistence classes. This is an easy way to add on additional functionality while keeping the original properties and methods in tact.

If you need to transform persistence objects to domain objects used by the application, I would recommend putting a constructor or static Create method on the domain objects that take a persistence object and then transforms it into a domain object. You can do the same thing going back to persistence.

using MyApp.Domain;

public class Customer
{
    public string Name { get; set; }
    public string Address { get; set; }
    public int ID { get; set; }

    public static MyApp.Domain.Customer Create( MyApp.Persistence.Customer pcustomer )
    {
        return new MyApp.Domain.Customer
        {
            Name = pcustomer.Name,
            Address = pcustomer.Address,
            ID = pcustomer.ID
        }
    }

    public void Persist( MyApp.Persistence.Customer pcustomer )
    {
         pcustomer.ID = this.ID;
         pcustomer.Name = this.Name;
         pcustomer.Address = this.Address;
    }

}

Here is what the partial class might look like. The key is to have the namespace of the class the same as the namespace of your generated persistence type.

using MyApp.Persistence;

public partial class Customer
{
     public string FormatedAddress
     {
         // I now have access to all the generated members because
         // I'm extending the definition of the generated class
         get
         {
             return string.Format( "{0}\n{1},{2} {3}",
                                   StreetAddress,
                                   City, 
                                   State,
                                   ZipCode );
         }
     }

}

Upvotes: 0

Kamil Krasinski
Kamil Krasinski

Reputation: 529

I would say design pattern depends entirely on the scale of the project and how "future proof" you want it to be. How many users would be using the software? Is the data to be accessed by many concurrent users? How "up-to-date" should the data be when accessed by a user?

If it's a small project keep it simple but allow yourself place to modify it without having to change entire application. In bigger projects it's useful to ask above questions before deciding on design pattern.

Regardless of the scale it's useful to create at least following separate layers:

DAL -responsible solely for updating and retrieving data

Business logic - a set of objects and methods that represent the process software is responsible for (only business logic has access to DAL)

UI - serving the purpose of presenting the data to the user and taking user's input based on business logic (UI references BL layer and only through it's rules it can access and modify the data)

This way you can modify any of the layers without affecting the others and as the project grows it can become very useful.

Upvotes: 1

BigL
BigL

Reputation: 1631

I'm new to the design patterns too but i think the best solution would be to put a Business layer on top of your generated classes and DAL. Then in this layer you could implement your custom methods and attributes for your classes, maybe you should consider using POCO objects for that.

Upvotes: 0

Related Questions