For my next web site I would prefer not to write everything from scratch. At the same time I don't want to be looked to much into a framework. So I would like something that I can use at all levels.
Access the DB (SQL Server) directly (The DB layout should not be much more complex than a self written app)
Business logic
Interface components (Web parts/Controls) -For example login, most read articles.
For the frontend there should be sample pages that I can easily change.
The app will be a bit like DIGG, but with a different frontend. There is a framework called
KIGG. But I dont know much about how it meets my criteria.
Kigg meets most of your criteria - I would start there. There is now a site built on top of Kigg called http://DotNetShoutout.com which shows you some of what the framework can do.
Related
I am currently a front end developer. I know HTML and CSS pretty well, I'm OK with jQuery and know some Vanilla JS. I have an idea for a website I want to create where I will be storing data for products (data that I will be grabbing from various websites around the web). It's basically a help me choose application where the user will go through some steps and be given some choices based on their selections. This site is nothing new, but it's more for learning purposes/portfolio work.
Most of my co-workers use ASP.NET and I've seen that you can setup a website like this using ASP.NET and the provided server controls along with C#, however, I want to take another route that allows me to do the same thing NOT using ASP.NET (C# is OK and preferred if that is possible) in that I can grab data, store data, and bind data to my page.
In addition to this, I would like to do this on the Mac.
Here's a list of things I have looked at:
MongoDB (I was really confused by the setup and didn't read anywhere that this would definitely be the solution).
AngularJS
EmberJS
BackboneJS
Several other JS frameworks
Ruby on Rails
Note about the above: Some of the above might be the solution, but I don't want to start spending time learning them only to realize a week in that this is not going to help me get to my goal.
If this post would be better suited for another stack site please let me know. Thank you.
To create a basic website with a persistence you'll need to deal with three parts the front-end (client), back-end (server) and the persistence (database). Of the things that you've listed Angular, Ember and Backbone are all front-end frameworks. They each have their own way of approaching the issue but they all work in the client facing part of the project so views, interaction and dispatching data to the backend. Rails is the only thing that you've listed that's a back-end framework, another option for the back-end if you're more familiar with JS might be Node and Express. Node allows you to build a server in JS and Express is one of the more popular Node frameworks. That section will be responsible for getting the calls for data and calls with data from the front-end and dispatching the appropriate response. Rails typically works with with a SQL database like MySQL or PostGres out of the box because Rails' active record is meant to work with SQL. Mongo is a NoSQL database and I think people are getting it working with Rails but I don't know that it's highly common. Mongo's shell is pretty much javascript and it stores data as JSON (not technically but close enough) so it's been a comfortable choice for JS developers learning back-end. Either Rails or Node can get a server up and running locally on your machine so you can work with the full architecture. So what it comes down to really is picking one of each from those sections and making them play nicely together. For your purposes I would think that the way to go would be either a basic Rails app (probably with MySQL) and using jQuery ajax calls to manage some calls from the front-end or building something with the so-called MEAN stack (Mongo, Express, Angular, Node) which is all JS and using Angulars built in http functionality to handle those calls. Hope this at least narrowed the field of research a bit. Really thats a pretty open question and there are a lot of options.
What is your webhosting site? I suggestPhpmyadmin Or Mysqldatabase You can create tables and strings where you can put the websites you wanna "grab" data from and put a little javascript in there to tell your website if blahblahnlah =blahblahblah then get id="website1"
Some clarifications:
At first, you need to distinguish between a server side language (used to program the functionality) and a database (used to store data).
C# is a language of the .net framework. Regarding websites, there's no C# without ASP.net.
There are two major groups for realizing back end solutions: PHP (market share ~ 40%) and ASP (~ 25%). PHP is a programming language, ASP.net incorporates several programming languages (mainly C# and VB.net).
Both worlds are able to connect to databases: For PHP, this is mainly MySQL, for ASP.net it is mostly Microsoft SQL server.
My company has a fairly old fat client application written in Delphi. We are very interested in replacing it with a shiny new web application. This will make maintenance a breeze and many clients want a web application.
The application is extremely rich in domain knowledge, some of which is out of our control. Our clients use the program to manage their own clients and report them to the government. So an inaccurate program is a pretty big thing. The old program has no tests. We are not sure yet if we will implement automated testing with the new one.
We first planned to basically start from scratch. But we are short handed and wanting to basically get everyone on the web as soon as possible. So instead of starting from scratch we've decided to try to make use of the legacy fat-client database.
The database is SQL Server and can be used in SQL Server 2008 easily. It is very rich in stored procedures, functions, a few triggers, and lots of tables with over 80 columns... But it is decently normalized. We want for both the web application and fat client to be capable of using the same database. This is so that if something breaks badly in the web application, our clients can still use the fat client and connect to our servers. After the web application is considered "stable", we'd deprecate the fat client.
Has anyone else done this? What tips can you give? We want to, after getting everyone on the website, to slowly change the database structure to take care of some design deficiencies. What is the best way to keep this in a data access layer so that later changes are easy?
And what about actually making the screens? Is there any way easier than just rewriting an 80 field form in ASP.Net? Are there any tools that can make this easier?
The current plan is to use ASP.Net WebForms (.Net 3.5). I'd really like to use MVC, but no one on the team knows it including me.
We are not sure yet if we will implement automated testing with the
new one.
Implement automated testing. What's the point in replacing one buggy program with another?
Good question, but "Slowly change" the db structure after getting everyone on the website, sounds like a joke...
I would rather take the opportunity to create a fresh db structure, write a bulletproof migration script for you db, that you can try out and rewrite a zillion times without any side effect fro your clients, and then write whaterver you want (fat/web) on the new db, have it tested and migrate everyone when it's ready.
I have a couple suggestions:
1) create a service layer to abstract away the dependance on the DAL. In a situation as you describe having a layer of indirection for the UI and BLL to rely on makes DB changes much safer.
2) Create automated tests (both unit and integration), especially if you plan on making fairly significant changes to the Domain or Persistance layers (BLL/DAL). To make this really easy you should always try to program to an interface. This makes your code more flexible as well as letting you use mocking frameworks (Moq is one I like) to ensure your tests truely are unit tests and not integration tests.
3) Take a look at DDD (http://domaindrivendesign.org/) as it seems to fit pretty well with the given scenario. At the very least there are some very useful patterns that can help make your application more flexible.
4) MVC isnt very hard to learn at all, it is however an easy way to get unit testing setup for the UI as a result of the MVC architecture (testing the controller and not the view). That said, there is no reason you couldn't unit test web forms, its just a bit more work. MVC really is just a UI framework/design pattern (more Model2 but we can ignore that for now). It gets you closer to the metal so to speak as you will be writting a lot more HTML and using a Model (the 'M') for passing data around.
For DDD take a look at Eric Evans book: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
Hope that helps
ASP.NEt forms is a no starter, is completely inappropriate for something like this. I recommend to start with something like Creating an OData API for StackOverflow including XML and JSON in 30 minutes, then build your Web app on top of that (ie. push it to the client, use JQuery/Silverlight).
I'm looking for best practices and good ideas rather than a proper solution.
scenario: I work in a web agency and thus we are plenty of websites from several customers. They're built upon a cms we made, so websites are quite identical for the 90% of code. However, remaining 10% struggles me and my team as it involves not only the presentation layer but behavioral logics too (ex: a website1 requires simply user/pass registration while website2 needs more data, facebook connector, etc. But this is a very easy example).
Making ad hoc development for our customers is becoming painful as keep each version aligned is getting really hard for us
What I really dream to have is an extendible website that works by itself, but in which I can override a part. This behavior should sound like "look for the specific part, if it doesn't exists get the base one". The parts could be a method, a class, a page, a control, a static file.
example:
Suppose I want website2 to have an own login component, let's so imagine that we have a situation like:
/website_base
|_ login.aspx
/website1
/website2
|_ login.aspx
So, if I ask for www.website1.com I'll get /website_base/login.aspx, but if I ask for www.website2.com I'll get /website2/login.aspx
Any idea?
Thanks
PS: we work with asp.net 3.5 framework.
There are couple of ways to achieve this.
Approach 1:
1. Split the common functionality in modules and create a pluggable structure. (like DotNetNuke) Obviously this will be more time consuming initially but over the period of time it can make itself like a product.
Approach 2:
Firstly - I would create separate solution for each client for better maintainability. This will save me a lot of hassle while maintaining the source control and when one client comes back with issues and we have multiple releases for a single client.
Secondly - From my core solution, I will identify most commonly used artifacts for each layers and move them to a core assembly.
a. For example – In UI you can use themes to give different looks for each client. Have a default master page which comes with the core site structure. All client specific details like Logo, name, contact details etc… can be configured using some DB fields.
b. In Business Layer and Data Access Layer – core functionalities like Membership, Logging, CMS related Entities etc I would have as a dll
i. I will derive my client specific logic from these core classes.
Last but not the least – how you deploy your code and how your IIS VD structure looks like… I believe it will be totally dependent on how the solution is packaged.. I would create a deployment package for each client which will give them the ability to deploy it to any server wherever they want until you have specific issues about proprietary software hosting.
Look into ASP.NET MVC. It is much more extensible than Web Forms, can be integrated into your existing Web Forms application, and it is very easy to build reusable custom components like what you are describing.
Otherwise, I would suggest looking into WebParts and developing reusable custom server controls for the components that you need. This way you can encapsulate the complex functionality within a single UI control without having to write repetitive code. WebParts are also compatible with Personalization, which you can leverage to manage the variance between which sites use which controls.
I definitely recommend MVC as the way to go for building extensible .NET web applications, but learning a new technology always incurs a cost in the time it takes to understand the new paradigm. I hope this helps you.
I found a smart solution here: http://www.codeproject.com/KB/aspnet/ASP2UserControlLibrary.aspx
Check it out
I'm not sure I'm asking the right question here, but I'm looking to provide web based functionality from one ASP.NET application to another remote 'portal-like' application. Is it possible to simply give the portal a DLL? As an example, let's say the SaaS web app has a patient-entry form that I want to be able to use from the portal application. I would like the portal app to be able to set preferences (permissions, color, style, etc), make a function call, and have that capability presented within a certain div or something. Is there any .NET technologies that provide this kind of integration?
EDIT:
Here is a link to a quick diagram I made trying to describe the scenario: http://img.ly/ESG. I know there are other ways of doing this (eg JSON-P calls), but I need to give the portal developers something they can control on their end. Also, if anything changes they'll know I will send them a new version of the DLL which will indicate to them the new functionality.
I'll give you a shopping list of things to check out:
DotNetNuke:
http://www.dotnetnuke.com/
Workflow Foundation -
http://msdn.microsoft.com/en-us/netframework/aa663328.aspx
Microsoft SAAS platform -
http://www.microsoft.com/serviceproviders/saas/default.mspx
Depending on exactly what you're looking for, you might also research "multitenancy".
To answer your original question, yes, you can do it with DLL's, but there are easier ways to do it.
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.