Business Layer advice needed

[semaphore]

One more thing, parameters. Should I keep them in the business layer?

Business Layer

 Public Function EditUpdateLog(ByVal query As String, ByVal info As SupportObject)

        Dim sqlParameters As SqlParameter() = New SqlParameter(10) {}

        sqlParameters(0) = New SqlParameter("@Id", SqlDbType.VarChar)
        sqlParameters(0).Value = info.Id
        sqlParameters(1) = New SqlParameter("@StartTime", SqlDbType.VarChar)
        sqlParameters(1).Value = info.StartTime
        sqlParameters(2) = New SqlParameter("@EndTime", SqlDbType.VarChar)
        sqlParameters(2).Value = info.EndTime
        conn.EditUpdate(query, info, sqlParameters)
        Return Nothing
    End Function

No i think you should rather keep them in a CSV and import them every single time. That way its consistent.

 

[Solarion]

No i think you should rather keep them in a CSV and import them every single time. That way its consistent.

I've learned to appreciate your sarcasm. You actually do bring a laugh every so often :crylaugh:

 

[Solarion]

Why do you have SQL stuff in your Business Layer and not your Data Layer?

It's somewhat confusing. I have an update procedure in the data layer, however when dealing with different parameters how do I cope with that?

 

[Hamster]

It's somewhat confusing. I have an update procedure in the data layer, however when dealing with different parameters how do I cope with that?

I'm not following, so I'm just gonna give you some general advice:

Data Layer

public interface IDataAccess 
{
    void Update(int id, DateTime start);
}

public class DBDataAccess : IDataAccess
{
    private readonly string _connStr;

    public DBDataAccess(string connStr)
    {
        _connStr = connStr;
    }

    public void Update(int id, DateTime start)
    {
         // Do all the database and parameters stuff
    }
}

Business Layer

class BussinessStuffs
{
    private IDataAccess _da;

    public BussinessStuffs(IDataAccess da)
    {
        _da = da;
    }

    public void StartThisThing(int id)
    {
        _da.Update(I'd, DateTime.Now());
    }
}

So that being how you would structure this, generally speaking, what is it you do not understand?

 

[Solarion]

Thanks Hamster that has helped tremendously.

 

[gkm]

...

 Public Function EditUpdateLog(ByVal query As String, ByVal info As SupportObject)
...

Also, in general I do not like passing around the query as a parameter. Just define it as a constant string in the area (the class or the function) you plan to use it. Then you can easily follow Hamster's pattern of passing around only the business relevant data as parameters.

 

[Solarion]

Also, in general I do not like passing around the query as a parameter. Just define it as a constant string in the area (the class or the function) you plan to use it. Then you can easily follow Hamster's pattern of passing around only the business relevant data as parameters.

Noted. Thank-you both for some awesome advice!

 

[Solarion]

Why do you have SQL stuff in your Business Layer and not your Data Layer?

I have resolved that now thanks for the tip. In the data layer is all the SQL stuff and I have another class called DB which has just three functions: Insert, Update and Execute pull data. In the business Layer I simply have small function interfaces for the presentation layer.

Also, in general I do not like passing around the query as a parameter. Just define it as a constant string in the area (the class or the function) you plan to use it. Then you can easily follow Hamster's pattern of passing around only the business relevant data as parameters.

Thanks gkm. That is the next thing I will be doing today, removing all the query's as parameters. Great tip!

 

[gkm]

A pleasure. Hope you are having some fun in the process.

 

[Solarion]

A pleasure. Hope you are having some fun in the process.

Yup!

 

[Solarion]

It's really all about independence of layers isn't it?

 

[gkm]

It's really all about independence of layers isn't it?

Yes, that tends to make programs easier to understand and fix.

 

[Hamster]

It's really all about independence of layers isn't it?

Setup rules/boundaries for your layers and stick to it. Ask yourself: "What is the one thing this [code/class/layer] suppose to do?".

Suppose the best way to explain it to students etc. is to think of code as little lego blocks that you can put together in different ways to do different things. A bit generic I suppose but experience teaches you these things. The saying goes that you should write code as if it will be maintained by an axe murderer that knows where you live (most often, that is you in six month's time). Very extreme but the idea holds true - it is more important to be able to read and maintain code than it is to write fancy code. When these "smart" guys write their clever code in nested lambdas, callbacks and sync/awaits the rest of the people in the office cry. Keep it low tech, simple and readable.

 

[FarligOpptreden]

Setup rules/boundaries for your layers and stick to it. Ask yourself: "What is the one thing this code/class/layer suppose to do?".

Suppose the best way to explain it to students etc. is to think of code as little lego blocks that you can put together in different ways to do different things. A bit generic I suppose but experience teaches you these things. The saying goes that you should write code as if it will be maintained by an axe murderer that knows where you live (most often, that is you in six month's time). Very extreme but the idea holds true - it is more important to be able to read and maintain code than it is to write fancy code. When these "smart" guys write their clever code in nested lambdas, callbacks and sync/awaits the rest of the people in the office cry. Keep it low tech, simple and readable.

*async

 

[[)roi(]]

When these "smart" guys write their clever code in nested lambdas, callbacks and sync/awaits the rest of the people in the office cry. Keep it low tech, simple and readable.

did a FP piss in your OOP soup...

 

[Hamster]

*async

I blame autocorrect

 

[Solarion]

Setup rules/boundaries for your layers and stick to it. Ask yourself: "What is the one thing this [code/class/layer] suppose to do?".

Suppose the best way to explain it to students etc. is to think of code as little lego blocks that you can put together in different ways to do different things. A bit generic I suppose but experience teaches you these things. The saying goes that you should write code as if it will be maintained by an axe murderer that knows where you live (most often, that is you in six month's time). Very extreme but the idea holds true - it is more important to be able to read and maintain code than it is to write fancy code. When these "smart" guys write their clever code in nested lambdas, callbacks and sync/awaits the rest of the people in the office cry. Keep it low tech, simple and readable.

+1

I will possibly post the project here once I'm done with it to get some feedback. The way at is at the moment, each layer is independent of the other and can be used on other projects. I have tried to avoid over complicating things. I've seen some 2 or 3 form projects that have so many layers and calls to wherever that it was just a mess.