I have a working WinForms application, written in c#, which is divided in several layers (Data layer, Model, business logic, common layer, etc). I would like to allow users to use web browser also for data manipuolation. Do I need to make some kind of in-between layer, or I am safe with using business layer from Web forms? Also, what kind of MS technology should be used on the web layer, as I see that we can use both classic ASP.NET pages, Silverlight, or maybe something else? The application itself has several forms for entering data, and many, many different forms with charts and reports.
Thanks in advance.
It's hard to make a recommendation without knowing your existing app details. There's also no one right answer. Silverlight, ASP.net (MVC), Javascript/jquery/ajax are all good technologies that have their place and use. But, as you decide for yourself, here's some thoughts and things to consider.
A thick winform app is typically a fat client with local state. Your data model etc... may rely on state to be persisted across many requests in a fatter local process.
A thick winform app is typically used by the one user & process - unless you're coding concurrency, your app may not be thread safe.
A web process is shared by multiple users making requests - any shared state will need to consider concurrency and memory footprint.
You typically want the web process to hold less state and drive more of the client experience down to the client - thus the popularity in ajax, jquery etc... More javascript technologies.
Silverlight is closer to your winform process - it's hosted in the browser plug-in with the state and code being accessed by that one user. You will have to change the view layers to silverlight but you might be able to retain your model and data layers.
Running in a silverlight plug-in does have more restrictions (sandboxed) than a full winform app. http://msdn.microsoft.com/en-us/library/dd470128%28v=vs.95%29.aspx
Many folks like ASP.Net MVC - check it out.
Javascript approaches using ajax, jquery, etc... has gotten alot of momentum in recent years. Be aware that will be a bigger shift from your winform code which may be good or bad depending on how you look at it.
Related
I am on a quest to find the best method to implement this data structure in my WPF c# .NET 4.0 web application.
App Details: This application will have many users at one time. I'm working with a database that has 2 tables linked together, both with <10k rows, but they will grow with time. One table will need to be checked for updates periodically.
Question:
I created a dataset to hold all information. My unit test shows it takes ~0.2 seconds to populate the dataset from the database. This is no time if the dataset will persist across the application. Can it persist across the application for many users?
The other method I can think of is using observable collections for the data and storing them in a singleton. Is there any method that I am missing here or something that will work better for me?
I think you're misunderstanding some really important concepts here. First of all, WPF is not ASP.Net, WPF applications do not "run at server". WPF applications run at the computer that executes them (I.E the client) regardless of being an XBAP that runs inside Internet Explorer.
Therefore, you cannot have such thing as a "singleton" shared between many instances of your WPF application because each instance will be run on a separate computer on its own process. There's no practical way to share memory between these instances.
Then, if you need a "Web Application", WPF might not be suitable for your project. WPF is not a web technology, it is a rich desktop application technology that does not depend on the crappy implementations of HTML or anything like that.
Now, if you need (or desire) the richness and awesomeness and ease of development WPF provides, you will have to implement a Client/Server application, possibly using WCF or any other communications technology to enable your rich Client to communicate with the Server.
The "Server" will be an application responsible for querying the data from the database, then possibly caching it in memory, and then sending it to the client. Usually a WCF Service application is enough for this, although depending on your requirements you may need to implement more layers on top of it.
Beside this, I don't think there is a good reason to send a WPF client 10k rows of information, so you will have to come up with some paging mechanism in order to send the data in "chunks" instead.
Please provide more details about what you need and I can give you more insight.
For web based applications, why doesn't PHP need middleware to run - yet languages like Java, C#, etc do?
UPDATE:
Re-worded: Why doesn't PHP need a middle tier, or business layer separating it from the database, whereas the others do.
Assuming that by the term "middleware" you mean "a middle tier", or "a business layer" the answer is that none of them need it.
For example, there is nothing to stop you in C# (or more correctly, on the .Net Framework "stack") from writing code in web pages that directly accesses the database. Indeed, lots of prototypes start out this way.
The issue here is more around good practice - it is generally considered A Bad Thing(tm) to write web pages (sticking with the same example) that directly access the database and the reasons for this are many. Testability, security, good decoupled code - all these require you to separate your code out, and having several tiers is a natural way to do this.
Why do you not see as much of this with PHP? I think Jeff's latest blog post covers this well :)
I'd go as far as to say that C# (the language), .Net (the Framework), ASP.NET (especially ASP.NET MVC) and much of the documentation and tutorials encourage you to do the right thing and not punch a whole from the web page through to the database.
But there isn't actually anything stopping you from doing it.
The use case that can appear is the following:
You have multiple web apps serving data that is stored in a database. Let's say the web apps are:
Front-end for your desktop web experience
Front-end for your mobile web experience
Front-end for your APIs that you expose to developers
Let's say each front-end accesses the database directly. Then, your eng team decides that the current database should be replaced. Now you have the problem of rewriting code in every front-end.
If you had a middle tier to abstract the actual data store, you'd only re-write one layer of code. Additionally, having unit tests for that middle tier would ensure that the way the middle tier exposes data remains uniform, regardless of the data storage platform.
I am in the first step of the design of an application that would support two completely different UI, and I would like to do it with the minimum duplication of code.
The first UI would be a windows application (probably with WPF), that will be the most used, the second would be a web application accessed mainly through mobile devices.
Knowing that the WPF application have to work completely disconnected from the network
and that once in a while, it must be possible to synchronize the work done offline in a central server
Here is what I was thinking to do:
WPF version:
MVC style WPF application, SQL server compact/express on each workstation and entity framework for data access, organize so that the WPF model, the entity model, and the controllers are in a separate assembly.
In addition, we will need a SQL Server database to synchronize the work of everybody.
Web version:
This is where things get blurry in my mind:
If I do an asp.net MVC application, modify it so that it is mobile friendlier, do you think it is possible to reuse the model, entity model, controllers, validation, etc. ?
I am still in the early stage of the design, and I am not familiar with asp.net MVC, so if you have other solutions, that would help a lot.
Also I will create and post here a POC when I will have a good design, so that it can be reused.
I would suggest the following:
Build a Service Layer (http://martinfowler.com/eaaCatalog/serviceLayer.html) using TDD (http://en.wikipedia.org/wiki/Test-driven_development) to encapsulate the functionality of your application.
Build a remote facade (http://martinfowler.com/eaaCatalog/remoteFacade.html) on the service layer to service remote clients (WPF, Andriod, iPnone, WP7 etc etc)
Read up on MVVM and Prism4 (http://compositewpf.codeplex.com/) before starting the WPF app.
Build the ASP.NET to access the service layer directly/in process.
Hope this helps, good luck!
If you're developing in WPF then forget ASP for your web based code. Structure it using MVVM pattern.
It's not a vast step change to have the same WPF application switched to be browser based (that's part of the point for WPF), certainly far quicker than writing a second app. Have a look here for information about WPF (applications and browser).
What form of data transfer is required - have you considered MSMQ for passing data to the server. This then wouldn't care if there was a connection or not and once there is data would be transferred without any work on your part.
I just got a project to be build up from scratch. Its front end will ASP.Net and Backend is SQL 2008. The requirement is, the architecture of the app should be such so that we can have access to app from any computers(desktop, laptop, netbooks) as handheld devices as well like smartphones, PDA's, Tablets. Also it should be plugable in nature like FB and orkut. That is in future if the client needs to attach games or third party applications, then it should be plugged in without rewriting the entire thing again. Also client needs the entire web ajaxified either using the toolkits or JQuery.
I have prior experience of ASP.Net webforms applications with tiered arcitecture. So this time keeping his all needs, i am thinking of a web app with WCF Service. But i have no idea or experience about the pluggable architecture with SOA and MVC (all three). It seems if I implement all the stuffs, it will going to be a mamoth of codes. For pluggable arch I googled and found MEF on codeplex. So finally I came up with the following things :
ASP.Net MVC
MEF
JQuery
WCF
RESTful with AJAX
XML
Guys, i really need your help, I am unable to think how to place all these stuffs together. Or is there any other best alternative you can suggest for.
Also, there is one more requirement by the client is that he want the loose coupled code, that's reason i chosen MVC, the aspx page can only have the controls and required HTML, validation and other codes should be done in the Business Layer of the app.
it will be great help.
You should take a look at Orchard: it's an ASP.Net MVC CMS system that is very pluguable. You can add a lot of functionnalities through modules, and there are a lot of modules already implemented and accessible.
Even if you do not end up using Orchard itself, taking a good look at its architecture should be a very good starting point for your app, as Orchard responds to a lot of the same requirements you have, and as it is an open source project, you can get as much inspiration from it as you want.
More of a design/conceptual question.
At work the decision was made to have our data access layer be called through webservices. So our website would call the webservices for any/all data to and from the database. Both the website & the webservices will be on the same machine(so no trip across the wire), but the database is on a separate machine(so that would require a trip across the wire regardless). This is all in-house, the website, webservice, and database are all within the same company(AFAIK, the webservices won't be reused by another other party).
To the best of my knowledge: the website will open a port to the webservices, and the webservices will in turn open another port and go across the wire to the database server to get/submit the data. The trip across the wire can't be avoided, but I'm concerned about the webservices standing in the middle.
I do agree there needs to be distinct layers between the functionality(such as business layer, data access layer, etc...), but this seems overly complex to me. I'm also sensing there will be some performance problems down the line.
Seems to me it would be better to have the (DAL)assemblies referenced directly within the solution, thus negating the first port to port connection.
Any thoughts(or links) both for and against this idea would be appreciated
P.S. We're a .NET shop(migrating from vb to C# 3.5)
Edit/Update
Marked Dathan as answer, I'm still not completely sold(I'm still kind of on the fence, though leaning it may not be as bad as I feared), he provided a well thought out answer. I appreciated all the feedback.
Both designs (app to web service to db; app to db via DAL) are pretty standard. Web services are often used when interfacing with clients to standardize the semantics of data access. The web service is usually able to more accurately represent the semantics of your data model than the underlying persistence store, and thus helps the maintainability of the system by abstracting and encapsulating IO-specific concerns. Web services also serve the additional purpose of providing a public interface (though "public" may still mean internal to your company) to your data via a protocol that's commonly accessible across firewalls. When using a DAL to connect directly to the DB, it's possible to encapsulate the data IO concerns in a similar way, but ultimately your client has to have direct access to the database. By restricting IO to well-defined semantics (usually CRUD+Query), you add an additional layer of security. This isn't such a big deal for you, since you're running a web app, though - all DB access is already done from trusted code. The web service does provide an increase in robustness against SQL injection, though.
All web service justifications aside, the real questions are:
How much will it be used? The website/web service/database format does impose slightly higher overhead on the web server - if the website gets hammered, you want to consider long and hard before putting another service on the same machine. Otherwise, the added small inefficiency is probably not a big deal. On the other hand, if the site is getting hammered, you probably want to scale horizontally anyway, and you should be able to scale the web service at the same time.
How much to you gain? One of the big reasons for having a web service is to provide data accessibility to client code - particularly when multiple possible application versions need to be supported. Since your web app is the only client to use the web service, this isn't a concern - it's probably actually less effort to version the app by itself.
Are you looking to expand? You say it probably won't ever be used by any client other than the single web app, but these things have a way of gaining in size. If there's any chance your web app might grow in scope or popularity, consider the web service. By designing around a web service, you're already targeting a modular, multi-host solution, so your app will probably scale with fewer growing pains.
In case you couldn't guess, I'm a web service fan. But the above are also my honest (if somewhat biased) opinions on the subject. If you do go the web service route, be sure to make it simple - keep application logic in the app and service logic in the service, and try to draw a bright line between them when extending the two. And do design your service for efficiency and configure the hosting to keep it running as smoothly as possible.
This is a questionable design, but your shop isn't the only one using it.
Since you're using .NET 3.5 and running on the same machine, you should use WCF with the netNamedPipesBinding, which uses binary data transfer over named pipes, only on the same machine. That should mitigate the performance issue somewhat.
I like the idea because it gives you flexibility. We use a very similar approach because we can have more than 1 type of database storing our data (MSSQL or Oracle) depending on our customer install choices.
It also gives customers the ability to hook into our database if they choose not to use our front end web site. As a result we get an open API for little to no extra effort.
If speed is your most critical issue than you have to lessen your layers. However in most cases the time it takes for your web Service to process the request from the database does not add allot of time. (This is assuming you do your Web Service Layer Correctly, you can easily make it slow if you don't watch it.)