Business Logic Layer

I am programming data d开发者_如何学Goriven applications using asp.net with telerik controls (v2009 q2). I have a class named BLL which contains (almost only) static classes that return different objects taking some id as parameter. The generally return group of objects as Lists.

My question is that are there any architrectural flaws to this, always using static. I know people make their Busines Layer and DataAccess layer as different projects. What is the advantage of it being a project ? So I can add more functionality or just it is tidier that way.

Thanks in advance

---

Using static methods as your method of entry is not a particularly big concern. It really depends on whether you have areas of work where you need to store state, as static definitions may not allow you to store or separate state information. Fortunately, going backward from having used static declarations to member declarations is usually less painful than the reverse. You might not even encounter this as an issue if the items returned from such methods are solely responsible for state.

Separate libraries/projects are useful for partitioning units of work. There are no strict requirements that everything must be separated into different libraries, although you may see quirks with static member variables, particularly in multi-threaded apps, as mentioned by Dave Swersky.

Having separate libraries also gives you the following benefits:

1. Better separation of changes during development, as project boundaries usually coincide with source-control boundaries, allowing more people to work concurrently over the entire surface of your platform.
2. Separate parts that may be updated independently in production, provided layout and interfaces are compatible.
3. Better organization of what behaviors, features, and roles intersect for a given segment at each layer, whether BLL or DAL. Some developers prefer to strictly isolate components based on what users are allowed to operate on items provided in a given BLL.

However, some parties have found that large monolithic libraries work better for them. Here are some benefits that are important in this scenario.

1. Faster compile times for projects where older components and dependencies rarely change (especially important for C/C++ devs!). Source files that don't change, collectively, can hint and allow the compiler to avoid recompiling whole projects.
2. Single (or low-count) file upgrades and management, for projects where it is important to minimize the amount of objects present at a given location. This is highly desirable for people who provide libraries for consumption by other parties, as one is less susceptible to individual items being published or updated out of order.
3. Automatic namespace layout in Visual Studio .NET projects, where using sub-folders automatically implies the initial namespace that will be present for new code additions. Not a particularly great perk, but some people find this useful.
4. Separation of groups of BLLs and DALs by database or server abstraction. This is somewhat middle ground, but as a level of organization, people find this level to be more comfortable for long-term development. This allows people to identify things by where they are stored or received. But, as a trade-off, the individual projects can be more complex- though manageable via #3.

Finally, one thing I noticed is that it sounds like you have implemented nested static classes. If other people using your work are in an environment with intellisense or other environment shortcuts unavailable, they may find this setup to be highly troublesome to use. You might consider unrolling some levels of nesting into separate (or nested) namespaces instead. This is also beneficial in reducing the amount of typing required to declare items of interest, as namespace declarations only need to be present once, where static nested items need to be present every time. Your counterparts will like this.

---

Having the BLL and DAL in separate projects (i.e. separate assemblies) means that they can be used with different user interfaces without re-compiling, but more importantly that the boundary interfaces and dependencies of the DLLs are relatively well-defined (although it doesn't guarantee a great design, it at least enforces a separation). It's still possible to have a single assembly with great logical separation, so it's not required nor sufficient.

As far as the static methods versus business object classes, that could be unusual and it could have drawbacks, but it doesn't really affect whether your layers are separated or not.

---

If your application is stateless, all-static methods/classes shouldn't be a problem. However, if your app is multi-threaded and the BLL does read and commit, you could run into thread safety issues.

---

One advantage of a separate project is that if you need to update your application but only change the BLL, you can make your change, recompile the DLL and drop it in the bin folder where the application is deployed in IIS without having to redeploy the whole web application

---

My question is that are there any architrectural flaws to this, always using static.

One flaw with that approach is that you can't apply Interfaces to static methods. A possible work-around is to use a Singleton pattern, although you will need to be careful about threading issues.

I know people make their Busines Layer and DataAccess layer as different projects. What is the advantage of it being a project ? So I can add more functionality or just it is tidier that way.

Advantages:

1. Easier for multiple developers to work on (depending on your environment and source control)
2. Forced separation of logic / protection levels from the rest of your solution
3. Easier to group and manage if your BLL gets large

---

namespace BLL
{
    public class tblCity
    {
        public tblCity()
        {
            //
            // TODO: Add constructor logic here
            //
        }
        private int iCityId;
        private string sCityName;

        public int CityId
        {
            get
            { return iCityId; }
            set
            { iCityId = value; }
        }
        public string CityName
        {
            get
            {
                return sCityName;
            }
            set
            { sCityName = value; }

        }
        public int InserttblCity()
        {
            DBAccess db = new DBAccess();
            //db.AddParameter("@iSid", iSid);
            db.AddParameter("@sCityName", sCityName);

            return db.ExecuteNonQuery("tblCity_Insert", true);
        }
        public DataSet SelectAlltblCity()
        {
            DBAccess db = new DBAccess();
            return db.ExecuteDataSet("tblCity_SelectAll");
        }
        public DataSet CheckCityName()
        {
            DBAccess db = new DBAccess();
            db.AddParameter("@sCityName", sCityName);
            return db.ExecuteDataSet("tblCity_CheckCity");
        }
        public DataSet SelectDistinctCityWithId()
        {
            DBAccess db = new DBAccess();
            //db.AddParameter("@iCityName", iCityName);
            return db.ExecuteDataSet("tblCity_getLastId");
        }
        public int UpdatetblCity()
        {
            DBAccess db = new DBAccess();
            db.AddParameter("@iCityId", iCityId);
            db.AddParameter("@sCityName", sCityName);
            return db.ExecuteNonQuery("[tblCity_Update]", true);
        }
        public int DeletetbltblCity()
        {
            DBAccess db = new DBAccess();
            db.AddParameter("@iCityId", iCityId);

            return db.ExecuteNonQuery("[tblCity_Delete]", true);
        }
        public DataSet FindPropertyLocationSubCategory()
        {
            DBAccess db = new DBAccess();
            db.AddParameter("@iCityId", iCityId);
            return db.ExecuteDataSet("tblPropertyDetails_FindPropertyLocationSubCategory");
        }
        public DataSet SelectDistinctPLCNAmeWithId()
        {
            DBAccess db = new DBAccess();

            return db.ExecuteDataSet("tblCity_getLastId");
        }

    }
}