I am a student and in last semester i develop asp.net application - "Payment Helper for School" . In this new semester i will have subject "Graduation Project" and i thinking about develop my application.
In my old app i use:
ASP.NET web forms
mssql 2008 database
linq to query to db
I achieved technologies above at good level and i want learn another one - WPF and XML cause i see that employers demand these and to create "cheaper" data layer ;)
I think to use in new version:
WPF forms instead of ASP.NET
XML (XSLT etc) instead of MSSQL
i stay in linq to XML
Do You think that this is good develop of my app? I am now learning WPF from tutorials, but i want to learn it at practice. I think also about NHibernate which interesting me, but it is too much :/
What advice you can give me at developing app rely on WPF and XML db ?
Doing this would move your application from web based to windows based. Think of WPF as winforms.
If you want to keep this application web based, you could look at silverlight, its a subset of WPF.
I wouldnt change your storage layer from SQL to XML if the app is data driven. Otherwise your going to have to handle concurrency, file locking etc which SQL server does for you by default (row locking etc) Ie, if there is lots of writing / updating of data SQL server is a much cleaner option than XML. In this context, think of XML more of a language independent way of passing data around, and storing simple data structures that are primarily read only.
If this is a graduation project, perhaps focus instead on design methodologies, MVC, or MVVM if you do choose Silverlight. A plus for potential employers and plenty of depth for a dissertation.
Edit - id argue XML would be a more expensive data layer! For the reasons above its going to be more complex and therefore greater dev time. Additioanlly SQL server express is free and the advanced edition with full text search and SSRS is also free; we have loads of clients that use it.
Edit 2 - another option would be to use Flex. It would be a completely independent tech on the presentation layer (and from a Uni point of view this could be good as you may loose marks / not even be allowed to use stuff from a previous project) Then you could use a combo of XML and JSON to pass data between the Flex layer and .NET on the server. Just another thought for you!
Related
I have ASP.NET project and I want to know what is better to use.
ODBC connection and with Server Explorer (drag and drop make DataSet and modify it) or do some DBconnect class with connection to database, queries and use it for GridView?
When I use server explorer, I don't have good feeling because all logic is on aspx page and I do not separate from the application layer logic layer.
It will be a lagre application, databese(PostreSQL) have 18 tables and difficult constraints and application have to generate some documents etc. .
"Better" depends entirely on your situation. Is the purpose to get something done as quickly as possible for internal users at your company, or is this going to be a commercial site that will need to be highly extensible and needs to be as easy as possible to maintain? Will you need to integrate with other platforms possibly built using other languages at some point? The answers to all of these questions should affect your decision.
If you're looking to separate your project into distinct layers, then I would recommend an ORM such as NHibernate or Entity Framework (there are other commercially available ORM products out there, but these are the ones I'm familiar with and which you can easily get help with on this site).
Create a DataSource with LINQ to Entity. It let you the liberty of LINQ with the peace of mind of when you change something il will break your build so you will be able to debug more efficiently.
Well if you have total flexibility, I would recommend using C# ASP.NET 4 with MVC3 razor for the UI and application code. Use Entity Framework 4.1 code first for the data access layer.
This way you will always work with real objects that you create, and with List<realtype> instead of the total mess that exists with datasets.
I am trying to evaluate whether we should migrate from developing our product in ASP.net web forms (current technology) to Silverlight. I remember reading that silverlight development can add to development speed, so this is the main driver for me to think about this.
I am assuming that business logic development will take same amount of time, I am open to it if UI development speed will bring in significant benefits.
The App we have is a line of business data driven app. There are very few rich reports required, however the printable data reports need a lot of formatting (since the app is highly configurable in terms of data setup; for eg which columns have a merged header and then sub headers, which cells to show data in red, etc). Apart from this most of the UI is Asp.net webfrms for entering data.
Do you see any significant improvement we can achieve by moving to silverlight? We also need to consider time to migrate existing UI and the learning curve, but if that were not a constraint, what would be your view?
I could see you gaining a lot using Silverlight, especially with the awesome charting controls that are available. This is compounded with how easy RIA services makes creating data driven applications. That said, it really depends on your development team. If they are already familiar with Silverlight I would go for it, but if they are not be wary that initially it may be slower than if you were working with ASP.Net.
It's not an either or situation. You can use a Silverlight app from within your ASP.NET webForms app. So you could develop some functionality using Silverlight while leveraging your existing codebase and effort.
The two work hand in hand.
Can anyone tell me what the future is for asp.net dynamic data? It seems like it is being put aside in favor of MVC. Is it worth investing time in dynamic data applications?
Without branding, Dynamic Data applications can be created in minutes. It for your RAD webform developer who doesn't care about the UI layer. This would work well for just about intranet scenario. However, the MVC lineage is geared toward very different scenarios.
The Asp.net dynamic data entities web application compounds several layers into one. I know that Object Relational Mapping (ORM) is supposedly the future but when layers are not exposed, it can cause serious optimisation issues as well as making testing almost impossible. This is the case with both the ADO.NET Entity Framework (EF) model and the LINQ to SQL model. These are the only out of the box model providers availabe to Asp.net dynamic data entities web application. These do not work well, if at all with Microsoft Access.
However, when there is little time to architect a proper solution, Microsoft are ingenious when it comes to dirty ways to write applications. The dynamic data entities web is one such technology to add to their bow. You might be prepared to architect a Sql Server database roughly because you anticipate having to make changes to it later. If you want a quick know around website that you want to rip out later when you have more time Asp.net dynamic data entities web applications are for you? EF goes as far as foreign keys to definite relationships.
Looks like it will die on the vine to me.
Reference to my work before, asp.net dynamic data help me build a "quick + easy" data edit grid to user. I can customize the grid, configure to display what data to users.
But actually, aims of asp.net dynamic data is not purpose to do this.
On ASP.NET MVC 3.0, webgrid can generate by strong-type model with List or EF4.0 edmx ,it can do similar with asp.net dynamic data, so in my opinion, asp.net dynamic data has no future.
Background:
I am an intermediate web app developer working on the .Net Platform. Most of my work has been defined pretty well for me by my peers or superiors and I have no problem following instructions and getting the job done.
The task at hand:
I was recently asked by an old friend to redo his web app from scratch. His app is extremely antiquated and he is getting overwhelmed by it breaking all the time. The app in question is an inventory / CRM application and currently each customer requires a new install of the app (usually accomplished by deploying it on a different domain on the same server and pointing to a new database).
Currently if any client wants any modifications to the forms such as additional fields, new features, etc my friend goes in and manually adds those fields to the forms, scripts, database etc. As a result all installs of this application are unique. There is no one singular source repository and no one single version of this app. Generally new features are overtime rolled into the other sites, but still this is done on an individual site by site basis.
I will be approaching this on a very modular basis. Initially I will be coding a module that will query an external web service for some data, display and store it, and periodically update it automatically. The next module will likely be for storing and displaying inventory data. This way I want to over time duplicate the current feature set of his app 100% but do it incrementally.
The Million Dollar Questions
I want to make the app have user
configurable form fields. The user
should be able to go to an admin
page, create a new forms page of a
certain category, and then specify
what fields he wants in there. He
could say 'create a new text field
called Item # and make it a
requirement" and that will get
stored somewhere. All forms will be
dynamically rendered to screen based
on what the user has configured. Is
this a good way to go about the
problem of having no idea what a
customer could want in a form? and
thus be able to store and display
form data of any sort ? What sort of
design pattern should I follow here?
I am familiar with asp.net and
the .net framework in general and
have decent knowledge of javascript,
html, silverlight, jquery, c# etc
etc. I can work my way around web
apps in a good way, but I am not
sure what sort of framework or tech
I should use to accomplish this
task. Would ASP.net 3.5 webforms be
the way to go? or should I look into
ASP.NET MVC? Do I use jquery and ajax for
complete decoupling of frontend and
backend ? or will a normal asp.net
page with some spattering of ajax
thrown in working with a codebehind
be the order of the day?
Just looking for general advice before I start.
I am currently thinking of using ASP.NET 3.5 webforms, jquery for clientside animation, ui, manipulation and data validation, and sqlserver + a .net or wcf webservice for backend.
Your advice is much appreciated as always.
I've recently implemented a white-label ecommerce system for an insurance company that allowed each partner to choose their own set of input fields, screens, and order the flow of the application to suit their individual needs.
Although it wasn't rocket science, it added complexity and increased development time.
Consider the user configuration aspect very carefully In hindsight both my client and their clients in turn, would have been happy with a more rigid system.
As for the tech side of your question, I developed my project in VS2005, using asp.net webforms and webservices with a SQLserver back end, so the stack that you're looking at is definitely capable of delivering a working product. ASP.net MVC will almost certainly help as far as testability goes.
The biggest thing I would change now if I was going to start again would be to replace the intermediate webservices with message based services using nServiceBus, MassTransit or the like. While the webservices worked fine, message based communication should be quicker and more reliable.
Finally, before you start to code, make sure that you understand the current system's functionality inside and out. If the new system doesn't do something that the old system did, it will be pretty obvious to the end users straight away.
I have a few projects coming up that have a number of endpoints or clients that can hit the same data. For instance a site might have...
A asp.net MVC based end user facing website
A web based adminitration back end that can allow specific, limited updates from some users in situatiosn where a full client isn't useful (mobile web etc)
A full on rich client for administration so we can use touch and other techniques to really make the user experience for content management shine - these may be silverlight or full on WPF apps, as needed
The question is... whats the best way to connect all that? Right now I use a multiple project split for the MVC.
ProjectName.Core - this project has all the common models, all the repository classes and all the helper classes
ProjectName.Web - an MVC project that references the Core to pull in the repositories and models it needs
ProjectName.Admin.Web - another MVC project dedicated to the admin interface that references the Core to pull in the repositories and models it needs
(which will ultimately live on a seperate subdomain from the end user facing site)
Then the story peters out int he sense of clear guidance. When the time comes to build a WPF / Silverlight project to hit the data I can do one of the following to the best of my understanding now...
Convert the "Core" to provide a RIA style DomainService, and attempt to alter the MVC projects to make use of it. However there is little guidance on using MVC with RIA, RIA is in its infancy AND the WPF to RIA story is also still only thinly documented
Do the same as above, but using WCF. However WCF prings with it async complexity that I really want RIA to hide for me.
Fall back 20 yards and just bolt plain old web services onto the Core on top of the Repositories and Models I already have. This seems... old school :)
Any thoughs and input are welcome including pointers to examples and documentation. I want to make the best decisions I can now, and am coming up to speed fast on RIA and WCF so I can but community input is always helpful.
Thanks!
Take a look at ADO.NET Data Services (formerly known as Project “Astoria”).
On my way to work today I was listening to a .NET Rocks! podcast, "Stephen Forte on Data Access Options", and they very excited about this, especially for scenarios like the one you describe.
It's interesting stuff, and something I would check out sometime very soon.
I think there's something to be said about plain old WCF services, these can make use of your domain services and repositories and expose a model more appropriate for services. Too often I've found that simply exposing the domain model on the wire ends up with a duplication of logic on both the client and the server.
My advice would be for some sort of service layer, this has the logic of shaping your domain model into appropriate types for the wire. \
Ideally I'd like to be able to share my Domain Services between the client (WPF / Silverlight) and the server (ASP.NET MVC) and have different underlaying repositories (Linq to NHibernate / Astoria). Difficult with the asynchonous nature of Silverlight.
For the curious, it certainly looks like RIA Services is the win here. Build a single DomainService then consume it everywhere. Brad Abrams covers a lot of this ground at bit.ly/94fFx - it really helped.