views:

179

answers:

5

Say you had to quickly build a data-entry UI that works in a web browser, which must interface with a business layer, which must interface with a data layer.

You want to connect only to business objects, not directly to the database.

Most of the views of the UI will be simple CRUD operations, with edit/update happening within a grid.

But some of the screens will be more complex, representing many-to-many relationships.

What's the fastest way to achieve this in ASP.NET?

(Note: speed of development is high priority, code quality and re-usability are low priority.)

+2  A: 

Entity Framework + ASP.NET Dynamic Data?

wRAR
This is definitely the fastest way to achieve this in Asp.net.
James
Interesting that you came up with the exact same combination we've started using. I asked this question because I wanted to see what other options were out there. We're having a *lot* of problems with both technologies at the moment. Entity Framework - can't get a simple update of a relationship on a table working; this would have been absolute child-play in Linq! Dynamic Data - very inflexible for our needs. We wanted to have insert inside a grid-view. Can't do it. We wanted to update only the columns that had changes. Can't do it. Had to write a complicated hack to fix this.
jonathanconway
A: 

I've written a lot of little business editors like this for my company in the same manner, get it to work quickly, if it's used or needs to be improved, I deal with that later.

Start up a new asp.net project. Add a class library to the solution and reference it from the asp.net application.

Asp.Net Application

  • Use Master Pages and Themes
  • Use a repeater for the data lists and command buttons for selecting and deleting.
  • The repeaters work well for inner lists as well, take note of OnItemDataBound and OnItemCommand.
  • Use Panels to hold the lists and editors, write some logic to control when to view editors and when to view lists.
  • If the logic is common, then make some base pages that new editors can use and override.

Class Library

  • Add your business objects
  • Add a Linq to Sql class and add database objects as necessary.
Joshua Belden
+2  A: 

If speed of development is the main priority, then go with what you know.

For example, if you know ado.net/enterprise library then go with that. If you know Entity Framework or LINQ, then go that route.

Without a summary of your skills, it's going to be impossible for anyone to tell you the fastest way to get something up and running.

Chris Lively
I think since we've already invested in Dynamic Data, we're better off going through with it. At least we'll have committed to a decision.
jonathanconway
A: 

To make it simple, you could use the some of the time tested controls and objects:

  • User Interface Layer: GridView for displaying and providing links for editing and deleting data. Clicking on Edit link may open up a new Asp.net web page that holds FormView for inserting and updating records. Use ObjectDataSource to link methods at the Business Logic Layer to Create/Read/Update/Delete records.

  • Business Logic Layer: Apart from creating CRUD methods, you might need to use light weight serializable data transfer objects to pass data between different layers and a custom mapper to trnaslate data from and to other layers.

  • Data Access Layer: Linq to Sql might make the data access and manipulation quick and easy.

arakkots
A: 

It depends on the complexity of the application. I would go with Linq to Sql. But then using Linq to Sql does not necessary provide a good abstraction between the business layer and the data access layer. But I find that using Linq to Sql you can quickly retrieve the data out of the storage and display it on the screen.

Also, if you want fast UI then take a look at dynamic data website. That also uses Linq to Sql or Entity Framework.

One question you must think is that if you need good design or RAD.

azamsharp