Don’t know enough to know if this design is a great idea or an incredibly dumb one …

Using C#, asp.net 3.5, SqlServer 2005,

Trying to incorporate some inversion of control together with 3-tier architecture into my current assignment.

Don’t know enough to know if this is a great idea or an incredibly dumb one:

I have created a User Interface Layer, a Business Layer, and a Data Layer.

The UI collects 4 values, News an instance of a Business Layer class (call it c) , initializing it with the 4 values.

The UI then calls a method of that instance of the Business Layer class to save the data.

The Business Layer class method creates a tsql string such as

String.Format (@”insert into table1 ( co开发者_如何转开发l1, ‘col2’, ‘col3’, col4) values ({0}, {1}, {2}, {3}); select @@identity”, c.one, c.date1, c.date2, c.four) ;

and passes the string to a int method of a class in the Data Layer.

the Data Layer uses the string as the CommandText of an ExecuteScalar and returns the @@identity to the Business Layer.

I would use a variation of the same concept to retrieve data through a datareader.

The amount of data is not going to be large and this isn't going to be a high volume application.

The way I have done this in the past was to pass the 4 values collected in the ui, through the Business Layer to the Data Layer set up sqlparms, pass the values to a stored procedure, etc, pass them back to the business layer, etc.

Oh dear! There's so much to say I don't even know where to start.

First off, I don't really see where does IoC fits here as you're newing up classes left and right.

Next, you're forcing your BL layer to construct an SQL statement, which it shouldn't do. What's even worse is that you're basically concatenating strings to get an SQL statement. This is a horrible, horrible practice (see SQL injection).

Now, I don't really see any "business logic" inside of your BL. And you're messing with raw ADO.NET, which is a huge no-no nowadays (except when you're optimizing performance). Check out NHibernate or BLToolkit.

Here's what I recommend. See what Service Layer is all about and try to flesh out "services" in your system. Since you don't really have any "business logic" for now, I see a IFooPersistenceService being the only service.

Next, read about MVP and MVC. This will help you build your UI better.

And finally, here's how I see the overall flow of control.

User enters several values in some form and clicks "Save". Your IView raises a Saved event, which is handled by the IPresenter. It then fetches these values from properties of the IView, creates a business object (or object graph for that matter) to hold these values, calls IFooPersistenceService (with Foo being the name of an object) to save it to the DB. IFooPersistenceService invokes whatever ORM you choose and hands back the value of @@SCOPE_IDENTITY to the IPresenter.

As soon as you start having any kind of logic, add an additional layer between IPresenter and IFooPersistenceService to hold the said logic.

See this (recursively) as well.

No, I think your new way is a lot worse than your previous way. Using String.Format leaves you open to SQL injection attacks if you aren't careful.

If you aren't really doing logic in your "Business Logic" layer, I would just remove it and have your "Data Layer" call the stored proc.

If it makes sense to you (and your team) and it works as intended, it's a fine design pattern, no matter what it is.

Software's Primary Technical Imperative is to reduce complexity. If you are doing something that reduces complexity in you and your team's mind, to hell with the paradigms.

My take on a good design in a webapp, is that the Business Layer is where you Model your application in an object-oriented way and define your business rules. The business layer is the core of your application. In a typical web app you will many times just pass data through the business layer, but it still creates a good separation between data and ui and anyways it is code that is very easy to write and maintain so don't worry to much if this appears to be unnecessary code.

To make your Business layer future proof and easy to test it should not have any knowledge of any of the external services it uses, it should just define a contract of what the services should deliver to your app, therefore you create interfaces for your services(IDataStorage, IMailService, ILogger...). This also allows you to easily swap the service implementations as they are much more a subject of change than your core business model.

You can consider your DAL as just a service the allows you to store and retrieve your data from a persistant store, this can be an xml file, web service or more likely a database. In this way your DAL is a service that gets data from your persistant store and translates this into your business entities.

When it comes to UI you should ideally create your business layer interface in a way that would allow for different UIs (Webforms, mvc, silverlight). If you create a good application it will live for many years and the UI will likely change many times and many times several UIs will be created. Your business layer should not care what you use as an UI layer, in this way you get a good separation between your layers.