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.
Related
I am a little confused as to how the identity framework works. For example in VS 2013 we can create an MVC application that the authentication is individual user accounts. Once we create it we can register with a username and password. But what if we wanted to have also a DOB in the registration or some other fields such as email or phone etc? Can we do this with the identity framework? What about the way the data base is structured, can we have a custom structure? Or if I want this should I be using forms authentication? Also what is the difference between the Identity framework and Forms authentication in terms of authentication?
Although your post has already been marked as answered, I’d like to add a little more info for future readers.
The first thing we need to understand with VS and Microsoft is that they’ve always tried to provide us with Templates to help us get started. There are many Pros and Cons to using Templates but the idea is that it gets you started quickly without having to manually include stuff yourself.
The idea of Templates is great but to the untrained eye, it provides Microsoft an opportunity to include stuff that THEY think you’ll need or better yet, what your application will need.
This opportunity includes promoting products such as Identity, Knockout.js etc...
In short, Microsoft is not wrong in doing that since the majority of the people do not second guess what is included in their project and because they…well…trust Microsoft.
A great analogy is when you purchase a new computer from a major retailer. When you arrive home and start your computer, you quickly notice that you have a bunch of pre-installed software running in the background (that you never asked for).
To the untrained eye, they will never realize that these are running in the background and their computer will work regardless. But for someone that is aware, he will most likely uninstall all of them and have a cleaner plate.
So Templates are similar to this...
As for the rest of your questioning, I’m sure by now you’ve found the answers.
Even though Microsoft sells ASP Identity as a single solution, Forms Authentication and Identity (Membership) are two distinct frameworks that work together, but serve different purposes:
Forms Authentication manages authentication session/cookies.
Membership/Identity is the store for user information (credentials, user demographics, etc.)
Look here for some additional information and links.
I have a question about a project we are planning to develop.
I will start by describing the project and later I will expose the possible approaches I see to tackle this task. I hope you can give me your opinion on them.
There are 2 main parts:
First part:
In our organization we want to create a kind central access point where users will log in (just one time) and from there they will have links (depending on their roles) to the different services we provide.
Approach:
We are using Active Directory to manage our users, so we thought to create this central access point with SharePoint Foundation.
Do you think that it is a good approach?
Second part:
We have services as a SharePoint were users can share documents, and also other web apps. The idea is to integrate all that in to the previously described central access point.
So far, so good. Now we were asked to develop a new web application. This application will be also part of our services; therefore will be needed to integrate it in the central access point.
Description of the application: It will be an application were 3 different roles of people will fill some information (in an specific order, 1st role will fill in, then the 2nd role, and then the 3rd role). After each step of filling information the next person will be informed by email that his/her part is ready to be filled in. The information to be filled in is an evaluation of a product (just for your information).
The managers of the organization will also want to have a control panel were they can have some statistic over the use of the application. There they can see thing like pending evaluations, evaluation per year, per role, …
Approaches:
As you will see our main doubt are about using
SharePoint Site <--> ASP .NET Pages (C#)
Workflow (SharePoint Workflow or just Workflow Foundation) <--> Using some flags in the internal code to control the workflow
We were thinking to:
1- Giving the idea that we would like to use SharePoint for our “central access point”. We would create the app as a SharePoint web (Using SharePoint Designer 2010 if possible). And apply the SharePoint Workflow to the process.
2- Create an ASP.NET Site and export it as a web part that we can integrate as an application in SharePoint. Try to use somehow the SharePoint Workflow on that. (We actually don’t know well how to do it).
3- Create an ASP .NET Site and forget about the Workflow tools, as our workflow is quite small and sequential, and control all that in the code with some flag.
What do you think about our ideas at the moment? Would you propose us something different?
Thank you very much for your help
Our SharePoint is the free version SharePoint Foundation.
Option 1 sounds the best fit for your approach as long as the web-app isn't aspiring to be something totally outside SharePoint bounds.
As far as basic workflow support goes, the SP Foundations should not be an issue. Refer this article for further details on workflow support in SP Foundations
Options 2 and 3 sound a little adventurous and will involve a lot of custom code which SP will provide you OOTB anyways.
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
There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.
This may sound a bit general, but I have a startup that is working on an ASP.NET (greenfield) suite of software applications. We are aiming to spend a substantial amount of time in the architecture phase to develop a strong foundation for our software. I was wondering if anyone has any advice, anything we should focus on or any suggestions for areas we should focus on to build a better suite.
Some things we are focusing on right now:
1. Session state requirements - should sessions be sticky or should we take server clustering session migration into account.
2. User login authentication - what are the major concerns in this space - LDAP, AD, custom SQL authentication systems etc.
3. The DAL - ORM vs Stored Proc
4. Integrating multiple ASP.NET applications in a single software suite. How it should look/feel. How it should be architected, etc.
I would appreciate any advice from any architects out there that have built similar systems from the ground up.
I know there are lots of solutions to session, but if you can create your framework to be session-free, you will avoid a lot of potential headaches. (There are lots of session-free options, but an obvious one is a hidden form field, somewhat like ViewState.)
Just some quick notes. I can't get too detailed since we went through this exercise where I worked last year - and I don't work there any more!
Start from the beginning using Enterprise Library, especially the Logging and Exception Handling application blocks. I've also found their Unity dependency injection library to be very useful.
Consider using Visual Studio Team Foundation Server. It's not just for source control, but can create you a complete continuous integration solution, complete with integrated bug tracking, code quality tracking, etc. If you've got the time and people, it's well worth a man-month to learn how to do an initial deployment.
You may want to buy one or more licenses of one of the Visual Studio Team System editions. You don't need these versions in order to use TFS, but they work well with it.
Consider globalization right from the start. Same with customization, if your suite will run on customer premises and be customizable by them.
You haven't said how large your team is, or is expected to be. If it's large enough, you'll want to spend at least a man-week learning a bit about what's available to you in terms of Visual Studio Extensibility. Your developers (and maybe also your QA folks) will all but live in Visual Studio, so the ability to customize it to meet your needs can be a big win. Whether it's just some macros and maybe some customized project or item templates, or whether you want to do add-ins or more, Visual Studio is very extensible.
Be certain to use WCF for any web services work. The older ASMX web service technology is now considered by Microsoft to be "legacy software".
Finally, be sure to find out whether you qualify for BizSpark, "A program that provides Software, Support and Visibility for Software Startups." And does so almost for free.
I saw a demo of Silverlight 3 at the PhillyDotNet User Group last night - WOW. Wow for business applications, not graphic applications. There is a learning curve, but you get a lot for it. For example, the demo showed a grid being bound to a table without needing to write any code.
Right out of the box you had sorting, editing, paging, etc. But it wasn't the lame stuff you normally get and then have to rework. For example the paging was smart enough to write the sql that would only bring back the 20 rows you needed for the page.
The demo continued with him putting a detail form on the page for editing. Again no code, but it was smart enough to know that it had the same datasource as the grid on the page. So as you were moving row to row on the grid - the detail form was showing the current row (and it was very fast).
Both the grid and the detail form were editable and as you changed a field in one the other would reflect the new value. The editing was smart enough to validate the field on its own. So you couldn't put a letter in a field that was an integer type, etc. It also limited the number of characters that could be entered based on the column size found in the database. All the date fields on the detail form automatically had a calendar next to them. You get the idea - no coding for any of this.
If this weren't enough, it can be used to build occasionally connected applications. So he showed how he updated a few records on a few different pages, had the option to revert back a field later (ctrl-Z), and then at the end submitted all the changed records to be saved.
Also, they said it works with Linq2SQL and the entity fraimwork.
So if I were building a new product now, I would really look into this as a way of differentiating my product. And I suspect that if you don't do it with Silverlight now, you will be rewriting it in a few years anyway.
Here is a link to a demo (not the one I saw.)
Some general thoughts. If you'd like me to expound on any of these, let me know.
Inheriting from a custom subclass of
Page instead of Page itself is a
great way to share functionality
across your site.
Nested MasterPages are good.
Charting: I've tried DevExpress,
Syncfusion, and MSChart control and
all have their own issues.
The built-in forms authentication is
pretty good. Building a site that
allows both integrated authentication
and forms authentication is tricky
but can be done.
I've tried using cross page postbacks
and I'm still not sure if I like
them.
Localization takes a lot of time
Come up with a good structure for your App_Themes and css.
Use Elmah to track unhandled exceptions