ASP.NET devs - how do you work admin systems?

Izi

Izi

Izi

Soldato
Joined
9 Dec 2007
Posts
2,718
gridviews / listviews are powerful and very useful controls, but what do you folks use for the more complex sections to your sites?

For example, take a news admin section which has multiple items related to it.

a news article may:

1) belong to multiple news categories
2) have an associated image gallery (or video)
3) may have more than 1 page of text
etc etc

So the gridview is great for editing smaller sections, but what do you do with sections which have multiple tables behind them? do you use the gridview to search / view items then put a hyperlink to a custom page to edit the item? Or do you use the details view to edit the item? Any help would be great
 
At work we avoid GridView like the plague; 9/10 it's easier just to use a repeater (following the same "link to edit page" pattern as Blackstar_Solar). GridView is too heavy, both in viewstate size, and the amount of wiring it needs to get it working in complex pages. Personally I believe it's another victim of the MS "make the web work work like windows" strategy.

akakjs
 
akakjs said:
At work we avoid GridView like the plague; 9/10 it's easier just to use a repeater (following the same "link to edit page" pattern as Blackstar_Solar). GridView is too heavy, both in viewstate size, and the amount of wiring it needs to get it working in complex pages. Personally I believe it's another victim of the MS "make the web work work like windows" strategy.

akakjs
Click to expand...
Actually agreed, 9/10 a repeater with .FindControl works just as well and is much more flexable.
 
cool, didnt think to use the repeater.

another question: how do you all design your websites? do you seperate BLL and DAL or not?

If you do, do you use linq and ORM in DAL? if not what?

Am i right in thinking that the business logic layer should be the code which handles all the processing of data. IE the manipulation of data between server and user.

The data access layer litterally gives the BLL access to your datastore?

In the past i have always put BLL and DAL together. In my latest project I have seperated them, but want to make sure I am doing it right.

what other coding practices do you use?
 
Izi said:
another question: how do you all design your websites? do you seperate BLL and DAL or not?
Click to expand...
Once you've got more than 3/4 pages I'd always separate BLL and DAL, however it can get a bit blurry sometimes, as you will end up with a fair bit of "UI" code (validation, event handling etc) in order to reduce the actions of the user down to a BLL method call.

Izi said:
If you do, do you use linq and ORM in DAL? if not what?

Am i right in thinking that the business logic layer should be the code which handles all the processing of data. IE the manipulation of data between server and user.
Click to expand...
We're still 2.0 at work so no lovely LINQ stuff :( And we use our own ORM system (it's fairly static and code heavy; but we can code-generate everything). I haven't been very impressed with MS's E-R framework (far far too complex to get one simple object to load from the db), and LINQ-to-SQL is dead in the water. I hear good things about NHibernate and Active Record for .Net.

Izi said:
The data access layer litterally gives the BLL access to your datastore?

In the past i have always put BLL and DAL together. In my latest project I have seperated them, but want to make sure I am doing it right.

what other coding practices do you use?
Click to expand...
For us the DAL holds the database to object mapping, and the basic objects themselves (we store most of the functionality in wrapper classes in the BLL).

akakjs
 
akakjs said:
For us the DAL holds the database to object mapping, and the basic objects themselves (we store most of the functionality in wrapper classes in the BLL).

akakjs
Click to expand...


thanks for the reply.

so in DAL, you dont have any code for "Select * from x" ? all that functionality is in BLL?
 
Izi said:
so in DAL, you dont have any code for "Select * from x" ? all that functionality is in BLL?
Click to expand...
Na we keep the queries in the DAL as well, and we return the results in this neat little lazily loaded list (where we can load the whole object at first or just the database primary key and load it later in a seperate request).

akakjs
 
I try to use linq to sql as much as possible. But don't forget that linq works perfectly on IEnumerable<T>.

As for layers, unless you actually have business logic, i.e. MUST perform security validation, MUST perform data manipulation before passing to data layer, I wouldn't bother with a BI layer, just call your data access stuff directly.
As for a data layer, there's little point in seperating off the layer into a seperate class libary unless you are going to reuse it.

But it might be worth putting you DAL it a seperate namespace within your website.

As for putting SQL in any layer, that's a HUGE no no. All SQL should be in stored procedures; make it much easier to maintain; also remove the problem of SQL injection.
 
Blackstar_solar said:
I try to use linq to sql as much as possible. But don't forget that linq works perfectly on IEnumerable<T>.

As for layers, unless you actually have business logic, i.e. MUST perform security validation, MUST perform data manipulation before passing to data layer, I wouldn't bother with a BI layer, just call your data access stuff directly.
As for a data layer, there's little point in seperating off the layer into a seperate class libary unless you are going to reuse it.

But it might be worth putting you DAL it a seperate namespace within your website.

As for putting SQL in any layer, that's a HUGE no no. All SQL should be in stored procedures; make it much easier to maintain; also remove the problem of SQL injection.
Click to expand...
I'd actually disagree on a couple of those points; Linq-to-sql looks really cool, however Microsoft have as much as admitted they've stopped development on it in favor of their Entity Framework project (which personally I don't like; it's too big), which kind of turns Linq-to-sql into a dead project.

The reason we have SQL in code is for source control, managing TSQL scripts in source control it a pain, and we don't actually have a dedicated SQL dev here, so all SQL changes are by the C# programmers themselves. Also starting with SQL2005 parametrized queries have the same cached execution plan benefits as stored procedures.

I would also advise not skipping the BI layer for DAL calls, as abstracting the DAL gives you more flexibility as the application grows.

akakjs
 
Thanks for the replies.

I came across this post http://www.adamtibi.net/post/2008/08/23/LINQ-to-SQL-The-Data-Access-Layer-DAL-Shrinker.aspx which helped me make up my mind.

Akakjs - as for Linq to SQL being dead, i don’t feel that’s a big problem for us. If linq provides us with what we need, then why would this be a problem? If we come across a problem which we find linq isn’t adequate, then we can use custom SQL code.

I also read on another Microsoft blog that it wasn’t dead as such, and they would release updates for it (bug fixes) but they currently had no plans of building on it further. It doesn’t mean that they might pick up on it in future.

For us, linq is brilliant. We have to develop very quickly and linq helps us with that immensely.

Once again, thanks for the replies - its been informative!
 
also from that post...

"We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well."

seems to me if linq has a good enough following, it wont die. and because many companies have invested time in to learning the lanquage i dont see it going quietly. Just my 2p.
 
You must log in or register to reply here.
Back
Top Bottom