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.)
Entity Framework + ASP.NET Dynamic Data?
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.
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.
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.
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.
Related
Could you tell me if it is a correct way to query data from custom control directly.
For example I'm implementing control that query data via business services from database. This let me avoid code duplication like
ctrl.DataSource = BusinessService.GetRequiedData();
ctrl.DataBind();
What do you think?
Is it merging of presentation and application layers? Should I avoid to use such data querying?
In my opinion that appears just fine. You're going to have to connect to some other layer, so the question is, do you need to separate your BusinessService layer from your presentation? The only answers I can think of are if you need to add a layer of security, or if you need to abstract out domain types to make your calls platform independent (like if your business layer is tied to Entity Framework or another technology - which it shouldn't be).
I think you are fine.
I have a small application developed in ASP.NET 2.0 WebForms. For learning purpose, I am thinking to convert this application to MVC 3 + Entity Framework. Below is the simplest example to simulate my application. Nothing fancy.
Application Layout:
(image should read "input fields" and not "files")
Architecture:
Key points:
Methods in Service layer is using ADO.NET SqlCommand ExecuteReader method to execute stored procedures
Most of the manipulation etc. logic is done in stored procedures. Hardly any manipulation of data in Service layer
Now I want to convert this application to MVC.
Questions:
What benefit do I get (technically) if I convert this application into MVC + Entity Framework?
How do I go about it?
I have looked at some basic MVC3 tutorials but they all talk about EF code-first, which I don't think will fit in my case since I want to use the existing stored procedures. Is that correct?
Note: I want to use the existing stored procedures. Say I don't have control on DB structure changes.
Update 1:
There isn't a single inline query in my application. Even the smallest little query is a stored procedure. Tons of them.
Using SQL Server and almost nil chances of changing to any other DBS.
Update 2:
My webforms application is 99% complete and can go live anytime but due to some business hurdles it hasn't. In mean while I thought if I can convert (i.e. develop) this to MVC, I will learn plus if it works out can go live (my first MVC) instead of the webforms one.
Before answering the specific questions I'll point out that you should probably seperate the choices into 2:
Converting the presentation layer to use MVC instead of WebForms.
Converting the data layer to use EF instead of ADO.NET.
Now for your questions
Benefits of MVC include better control over HTML, better testability, etc. Benefits of EF include abstracting away DB-specific things (you could theoretically replace SQL Server with MySQL, assuming an appropriate MySQL provider), LINQ support, etc. Of course there are also costs to such a transition.
Divide and conquer. As stated earlier you don't have to do everything at once. Start with the presentation layer and convert it to MVC. Remember that you can have mixed WebForms and MVC applications so you don't have to transition all your pages at the same time. Then convert your data layer to EF. Or start in the reverse order, whatever makes sense for your project.
[Not an expert in this topic] if you rely heavily on SPs than consider traditional EF. If you have only a few SPs then you could consider code first + handling the SPs with DataSets (potentially wrapped in custom built classes) to make everything work, though that might get complicated. As before, you don't have to move to EF if the cost is too high.
What benefits do you get? It is completely wrong question. You should ask what problems do I have with current solution and how will these problems be solved by replacing data access with EF or replacing presentation layer with ASP.NET MVC?
As I understand you want to do this just for learning purpose - it has no business drive. In such case there are some points which will get you some ideas:
If you don't want to replace existing SP logic with the common EF way you will get almost none benefits and you will not learn EF. EF allows using stored procedures either for retrieving mapped entities or for loading custom classes. Mapped entities usually represent either views or tables from the database - it is not clear here if you even want to define any mapped entities. The only benefit you get when loading custom classes is automatic populating of properties from the result set. It means that you will need class for each SP result which will have properties named exactly the same as columns in result sets. SPs in EF doesn't support multiple result sets (by default) and also doesn't support automatic loading of relations.
When moving from ASP.NET Web Forms to ASP.NET MVC + Razor you can be almost sure that non of your front end code will be usable in the new solution. You will simply create new project and do you front end from scratch.
As described by #marcind these two changes are completely independent - you can do one without other.
When is it appropriate to create a helper class for a sql server database using the asp.net framework? Basically I'm trying to create a minature wiki (with multiple pages) and storing all of the data/strings for a specific page into a table on it's own.
Always and Never.
Always, because you want good separation of your data tier from your business logic and presentation tiers (or model and view, or whatever framework you use). Make sure you're thinking of it in these terms, too.
Never, because this is already done for you, on several levels. There are numerous ORMs out there, including Linq-to-sql, NHibernate, Entity Framework, and more. More than that, what is ADO.Net but a set of classes to encapsulate your server?
Well it could be appropriate to return a single instance of a DbConnection object - that way you only specify how to connect to the DB in one spot.
You may find it useful to have a base class for your ADO layer which provides these generic methods to deal with the ADO (part of the .NET framework for connecting to SQL server).
You could have a helper method to populate an object from a DataReader using reflection too.
Also for putting parameters together to send to a SQL command or Stored procedure.
Hope you find this helpful. :)
It's heavily dependant on your project.
For code clarity, and your own sanity, you might find it easier to make a wrapper class for all of your Database manipulation. This way you can have the rest of your code work with native objects, rather than the contents of a DataReader.
Just my advice, but hopefully helpful.
I've received a project for internal use. My application has to store about 100 rows of meta data of a game and each row has about 15 fields maximum. Fields can be game name, game category, maker, source code path, etc. I will most likely have to join about 5-10 tables for each row of record. Only a few people are using it and will receive very little hits. Speed performance is not a much of an issue. The rows of data I have to present must be sortable and searchable
My current solution is to use ASP.NET's GridView control with ASP.NET's AJAX UpdatePanel to give it that ajax feel. I'm thinking of using LINQ-to-SQL as my data access layer. I'm thinking of building my own custom search engine but if there's an existing control that has this feature already, i would prefer to use that; anyone know of such control exist? Anyways what do you guys think?
Update #1:
I'm looking into creating a DynamicData website. Any have thoughts on that?
Use ext.js!
Look at the Grid Samples, its a very shallow learning curve and provides you with amazing results in little to no time.
http://extjs.com/products/extjs/
Basically, you expose your data via a web service (asmx or WCF, your choice), throw the Ext.Js grid onto your html/aspx page and point it at your webservice. Configure the control for things like sorting/searching/expanding/grouping/paging etc (use the api reference http://extjs.com/deploy/dev/docs/).
ASP.NET Dynamic Data looks really cool, particularly for sites where you've got:
lots of data
not a lot of worries about performance
no / little desire to skin / design the site
no / little desire to extend existing / write new functionality.
So I'd say that's a good match for your project.
Gridview is your best bet. It's so powerful if you know how to use it correctly. It does automatic sorting and if you can code pretty well you can get the data to be filterable(if that's a word). It also makes the Connection to the database for you....so in my opinion, you can't beat the gridview when it comes to reports like that.
It is very simple to retrieve data from a database and display it inside a DataGrid. However, what are the current practices to push the changes in the DataGrid back to the database? One can achieve this by inserting a lot of meta information, however, it is very tedious and not reusable.
There are libraries for persisting data across tiers, but as you say it isn't a simple task. LiveCycle DS ships with this capability when used in conjunction with Hibernate on the server. GraniteDS and Tide can perform a similar function, but for the most part you are left rolling your own. If you are using one of the many MVC frameworks available (I use PureMVC) it isn't difficult to create this type of functionality. Kind of tedious, but not difficult.
Which server side technology would you be using? You need to use HttpServer, WebService or RemoteObject's in Flex to push data to this server side app and that would then update the database.
Unless of course we're talking about a Flex/AIR Desktop App where connecting to databases directly is possible.
You can use RemoteObject, if you have a Java class on the server side that takes care of database connection and provides method to update database.
Just Create an ArrayCollection object from modified datagrid and pass it while doing a method call.
I think making changes to the database is the easiest part of this whole thing. The hardest part is making the DataGrid know exactly from which database table each cell comes from. If you're the one writing the query, then you can probably return a lot of meta-data, such as the private key and table name for each cell.