I'm new to the .net application. am trying to develop an application for Accounting Purpose. Am totally confused that how can I use the design pattern, MVC is preferred. I have to use this app both in Desktop and as a mobile app. App should be more secure.
So please guide me how to design the project. Can you please suggest any examples?
WebApi + MVC is good option I think but for this, should I create 2 solution for both API and MVC?
should it work smart phone as well as desktop?
Database-PostgreSQL
Application will have two parts:
Part I – Accessible to the client through the web page
Part II – Back-end accessible only to us (Company) where all the processing is carried out. Perform the initial setup once the client is registered – create the account in the accounting software and create the chart of accounts
Review and process documents
Accounting – the entries will be passed in the application and will be exported to the accounting software
First of all you can find many tutorials out there on the web about creating a ASP.NET MVC project with Web API.
This can be achieved in one solution as you will see in tutorials.
Example: Getting started with ASP.NET Web API
For the desktop and mobile support, I would like to refer to use Responsive Design. Using a library like GetBootstrap you can create websites that change their content dynamically for each type of device ( desktop / tablets / smartphones / ... ).
Now-a-days everything is mobile. So if you are developing something both for Web and mobile app, API has to be the first and only choice.
The reason behind is that--- More or less what Web shows, APP should also show that, but the layouts or UI are different(here comes the client-side). Moreover if APP needs some extra API, I do not think, that would be much overhead if certain extra APIs are written for the APP. Essentially One API codebase suffices both the paradigms.
It is always a good idea to seperate Client-side architecture with server-side architecture.
I would suggest to seperate the client and server(API), and that would be in best of interest.
Your .net application may serve as client side with MVC pattern where M can call API services and C as usually manages the business logic and V displays the results.
You can write API services(server/backend) in .net, nodeJS, PHP, GO any technology which can manage talking to servers. There also you can create certain architecture or flow of your requests.
Hope that helps
Related
Disclaimer: I do no have extensive SharePoint/.NET experience, mostly read through online Microsoft docs, so asking opinion in this forum.
I am modernizing 2 legacy microsoft apps. One is SharePoint 2013 site used for CMS and other is ASP.NET 2.0 web application having transactional frontend. New combined frontend must be JS based common for all screen sizes. Business wants most cost-effective solution, preferably on-prem. I am bit confused about the approach to unify both. 1) Upgrade path - Put ASP.NET into SharePoint farm and then modernize the UI pages. 2) Rewrite with SharePoint frontend - Build using SharePoint Framework (SPFx) which internally supports modern JS frameworks. 3) Rewrite without SharePoint frontend - Build a common JavaScript UI portal (ReactJS) and access the backend REST APIs (including SharePoint) sitting behind an API Gateway.
For Cost effective solution, don't use spfx / ReactJS. Their development environment settings are costly and expired in sometime by new version sooner.
One can rewrite using jsom in SharePoint online , as SharePoint online provides a very good code editor .
JSOM all operations are below :
https://www.codesharepoint.com/jsom/0/all-methods
Approach 1 (ASP.Net in SP Farm) - I would not consider this 'modernizing' as Microsoft's approach going forward is using front-end javascript based applications, which are extremely powerful with the amount of AD integration/Graph libraries/etc. made available. This feels dated in my eyes and could create issues down the road if the company ever wishes to migrate to SharePoint Online.
Approach 2 (SPFx) - This is where the Microsoft ecosystem is flowing with SharePoint modifications. It's also easy to tie into back-end services or other services using Azure App Registrations. There is a lot of flexibility here, you have the option to use ReactJS as well, among other frameworks. I would recommend this approach
Approach 3 (Custom App) - I have built solutions running off create-react-app and similar frameworks and I still try to leverage SharePoint if it is a significant part of the ecosystem as they have very powerful frameworks for tying into it such as PnPjs. It just makes integration so much easier, and you are working within the context of SharePoint vs a custom application on some other server which must be wary of authentication as well as the potential need of a back-end service for communication to SharePoint.
I am supporting an ASP.NET app, which is installed on a web server and a VB6 app installed on a different app server. There is code duplication in the VB6 app and the ASP.NET app. I want to use some of the code in the ASP.NET app in VB6. I believe I have three options:
Expose the required functionality in an ASP.NET web service. The VB6 app will consume the web service.
Rewrite a small section of the vb6 app in .NET and extend the asp.net app. This will eliminate some of the code duplication.
Setup a class library for the ASP.NET app. Install the vb6 app on the web server. Expose the required functionality from the class library in a type library.
Which option is best? I believe option 2 is best.
Option 1. That leaves your shared, already-tested code on the most modern platform.
This is very hard to answer, as it varies for each company and each situation.
As a general rule, I'm very much in favor of using web services where possible, especially if multiple applications are using the same logic for the following reasons:
If I have to change the logic, I can do it in one place and fix all apps that depend on it
The same can be said for database connection strings, etc.
A bug fix can also often be fixed in one place.
I've had difficulties with a particular database that I need to deal with, where the vendor's updates tend to break their .NET adapter. Twice I had to modify/recompile a ton of apps to resolve this. Since then, we made it a policy to connect to that DB only via web services, so I'll only need to update one app in the future.
When developing mobile apps, the simple fact that we already had all our code in web services makes it that much easier to write apps that are strictly UI and leaving the business/database access logic as-is in existing web services.
All of those are pretty much "Standard" arguments for the SOA approach.
All things considered, my first recommendation, not knowing your specifics would be option #1.
There is a fourth option - a total rewrite of the VB6 app, if it's feasible, and if you can convince those who control the budgets and time allotment. Even with that, you can use the Service Oriented Architecture and split much of the logic into web services.
Are there any good books or websites on this subject covering subjects like:
different migration scenario's (big bang, module for module, function for function) pros and cons
do's en dont's
tooling
handling customer expectations
We have a rather large winforms based product which we would like to migrate to the web. Migrating in a 'big bang' scenario would probably take at least two years. We're looking for alternative scenario's.
I'm especially looking for ways to handle the inbetween scenario, what options do you have to keep customers happy.
Let them use the windows application at the same time as the new web
application?
Let the windows application use the new features from the web
application via a service interface?
Accept the cost of double maitenance for a while to keep customers happy?
You are more likely be doing a complete rewrite. Because web is conceptually different from windows forms, there would be a lot of changes.
Your best bet is stop new development on windows forms app. Start writing a new app for the new features. Then start moving one isolated feature at a time to web.
You have two options for the UI
webforms - matches closely with windows forms model. If you are
using any 3rd party controls like devexpress, you can find the
equivalents in webforms.
mvc - It is more like re-architecting the whole presentation layer.
If your UI layer is already separated from business layer, then it
would be a good choice to go down the path of MVC. However the
development experience is totally different from doing windows
forms.
State
Maintaining application state is comparatively simple in windows
forms. In webforms you have viewstate to do that for you. But you are going to run in to rude shocks as you run into limitations of viewstate, especially when it gets too large.
In MVC, you are completely responsible for maintaining the state.
New skills
You require new skills to mimic state-full scenarios
Strong understanding of javascript, ajax, at least one javascript
framework like jquery. 3rd party commercial tool kits can ease some
of these pains.
Depending on complexity you might need web application frameworks
like Backbone.js /Knockout
Expectations
It would be very expensive to achieve the same responsiveness as windows app, as you will be messing with multiple technologies. Probably your users are going to hate the new app initially. Having skilled web designers on staff is very important
Based on our own experience with moving applications from desktop to web: carefuly inspect the architecture of your winforms applications and if possible - try to provide a web interface at the service or persistence level so that your windows applications use web services instead of directly talking to the database. Then you can let your users launch desktop modules from the application server using clickonce.
Such approach let us move to web quickly and users got the same GUI and a new way to access the application. In fact, it took like 3 or 4 months to redesign existing applications so that they use web services.
Then, we were replacing modules one by one, implementing them as web applications and maintaining both (clickonce and web) for a short period of time so that users were able to get used to new modules.
The migration of consecutive modules from clickonce to web was prioritized in an obvious way - we've started from modules that were used by most users. In fact, the initial release of the system has only one web forms module ready and remaining modules are being replaced for over 2 years now, one by one.
I am in the planning phases of building a new ASP.NET website. The website is really a transactional web application where the users will log in and perform basic CRUD data operations. For right now this website will be accessible through a traditional desktop browser and a mobile browser. For the mobile browser we will build a separate scaled down version of the site.
In the future we may decide to create native mobile applications for Android or iOS devices also.
So the question I have is what is the best way to design the system to easily support that? Here is what I am thinking. I am thinking of building out 3 tiers to the site. The back end will be the database - SQL Server 2008. We will use stored procedures for all data access. The middle tier will be a web services tier. This tier will be built using RESTful web services and will contain all of the business logic. These web services will provide access to the database. The front end will be built using ASP.NET. The front end will only contain presentation logic. These tiers will actually be deployed on physically separate servers.
Then I am thinking that when we decide to build a native Android or iOS app that we could build those apps to simply call the same RESTful web services that the main site is calling.
Does this seem like a reasonable approach? The only thing I can think of is that the way we are building it right now the web services would be behind the firewall and would not be accessible to the outside world. When we want to support a native mobile app then we would need to make the web services accessible to the outside world.
Any thoughts? Does this seem like a good approach for building a high availability, high usage web app that needs to support native mobile apps in the future?
Thanks,
Corey
I'm with Rober Harvey there. With ASP.NET MVC you can make the presentation site in no time, use as Models your web service; with the link that he gave you, set the site for mobile browsing, and use the web services for the mobile apps when you build them.
For me it looks like a good plan. Regarding the web services being public, you can protect yourself by implementing API keys in the web service, so only your apps can use it.
Are both completely different concepts? Or is there an overlap in their meaning?
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
Are both completely different concepts? Or is their an overlap in their meaning?
A web (application) framework is a lower level, generic toolkit for the development of web applications. That could be any type of system managing and processing data while exposing it's data and services to human users(via web browsers and other interactive clients) as well as machines via the http protocol.
A CMS is one type of such applications: a system to manage content shown in websites. Usually/historically, this mainly means managing (pieces of) text of "pages" shown in a web site, and useres that have different levels of access to manage this content. That's where the C and the M come from.
With a CMS, you can manage web content. With a Web framework, you build web applications.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
No. It would be correct to say that a web framework can be used to create a CMS.
Both contain parts that work on the backend as well as on the front end.
Often, a CMS is based on a web framework - sometimes CMS developers build there own web framework, and sometimes they even expose the API of this framework, so a developer can create extensions to the CMS in a way as if he would develop an application with a web framework. Drupal really does this, so you can create real web applications based on the integrated framework - with the upside that they will also be easily to integrate into the CMS.
But that(exposing the API of a web framework) is no necessary criteria for being called a CMS.
If yes, then should the Web Framework use the same technology as the CMS? For example could Ruby on Rails be used in combination with Drupal? Or doesn't that make any sense at all?
It's be possible to combine two existing systems build with these two, (e.g. because you want to show some data in a web site managed by drupal, that already exists in a Rails-based system).
But as Drupal also provides you some of the genric functionality of it's underlying web framework, it might not be necessary. You would have to manage and learn two very different systems and handle all the problems with there interoperation. So, I'd try to build a Website with only one of these if possible and only combine them if theres a good reason to.
They're different concepts. A CMS can be built on top of a web-app framework, but a web-app framework has no direct relationship to a CMS. Its at a lower level, providing a platform for any type of web-app to be built on top of it, of which a CMS is an example.
Drupal runs on php and Ruby on rails runs on, well, Ruby, so they wouldn't play together.
Just to muddy the waters a bit, Drupal describes itself as a content managment framework which is essentially a content management system with hooks to extend it. Which does create an overlap. The drupal overview describes this better than I could.
Would it be correct to say that a Web Framework is used for the creation of a front-end, while a CMS is used for the back-end?
It's not "correct" but it's not wrong, either. A web framework is a general concept -- many things count. A CMS is a specific concept, often built within a web framework. Sometimes CMS's are stand-alone web applications. More often, however a CMS is a back-end things that require a customized presentation front-end.
Should the Web Framework use the same technology as the CMS?
Shouldn't matter. At the end of the API definition, the Framework and CMS can have any implementation at all.
Web App Frameworks -- generally -- must either serve HTTP requests or plug into something like Apache.
A CMS is a glorified database, and any sensible API is good. Most often, however, they're also using HTTP as their interface protocol.
Could Ruby on Rails be used in combination with Drupal?
Sure. Purists will object, but there's no technical reason why they can't cooperate.