I am going to create a basic "CRUD" application that will "live" inside Sharepoint 2010. The data will be hosted on a SQL 2008 R2 Server.
Basically, there will be a few "Add" forms, some Queries and some Reporting (SSRS).
Honestly, the application doesn't really even need Sharepoint, but we are trying to get as many of these applications hosted inside Sharepoint as possible. (The application is currently a Microsoft Access application.)
I have experience creating these types of applications (ASP .Net) and have recently been using the Entity Framework. Generally, I design my Data Layer in a seperate Visual Studio Project (using EF) and then extendthe partial classes it creates and/or sometimes create another POCO layer to access the data (depending on how much "business logic" there is).
Anyway, the question I have is:
If I create a (Visual Studio) Solution (I know I have to target .Net 3.5, since because SP doesn't support 4.0 yet), can I use my usual "layered" design and create a seperate project (assembly) that conaints all of my Data Access (Entity Framework) and then have a seperate Project that contains all of the Visual Web Parts (that we design the Data Entry Forms in)? Will this work? Will I be able to call the exposed methods from the (EF) DAL from within the Visual Web Parts (after I deploy my solution to the SP Server)? Will I have to do anything "special" or will both projects get packaged up into a (what is it) "wsp" file and get deployed to SP? (Or, will I have to manually get my DAL Assembly added to the GAC, etc.)
Any examples or tutorials would be a big help to me too.
Also, if you think I am going about this all wrong, I am also interested in knowing how you would create a similar appliation. Is there a better way to do this? (I know I could create a BDC Model and access our SQL data via a Sharepoint List using the External Content Type. Although, for some reason it just seems like that isn't the "right path" for this particular application... I can't put my finger on it, but I am leaning toward just creating a "traditional" ASP .Net app that just uses SharePoint as its "hosting web server".)
Thanks!
Shayne
Can you do it: yes. Should you do it: probably not.
You hit it on the head. You are creating and ASP.NET application, not a SharePoint application.
Anyway, assuming you are going to have to proceed in this manner, here's my advice.
Build the presentation layer (web parts, application pages) using the SharePoint project template and SharePoint project items. This project can reference the assemblies that implement the remaining layers of your application. Visual Studio will then prepare a Solution Package (WSP) that can be used in testing and deployed to production servers.
You should do everything you can to make your application "fit" into SharePoint. It should use the same UI metaphors, respect branding, and so on. Nothing is more jarring to a user then to have pages and web parts that look and behave total different to SharePoint in the middle of a SharePoint site.
If you have the full version of sharepoint you can use Access Services, which will convert your Access application to a web app, just run the wizard
see this video for details: http://channel9.msdn.com/Shows/Access/Microsoft-Access-2010-Demo
Related
I am looking for an easy-to-implement solution for form-based ontology editing and I wonder if there are any active projects and which of them is the right path to follow.
I need to create instances of an ontology (lets call it ontology A) using forms (either web or desktop) and store them in a triple store (e.g. Virtuoso). I would like to hide as much details as possible regarding the ontological relationships between the entities defined in ontology A and provide a plain simple user interface for CRUD (Create-Retrieve-Update-Delete) operations based on the entity schema defined in ontology A.
For example, I have found two possible solutions in the protege ecosystem:
PropertyFormPortlet It is not a live feature in the current webprotege version.
facsimile project
As described in the respective paper this is a solution that has been implemented for a specific context. Therefore, adapting it to another domain would not be as straightforward as I would like.
I wonder, is there another solution (even out of the protege ecosystem) that could facilitate such a form-based ontology editing. Could somebody provide some guidance?
Just in case someone lands in this question, I write down my conclusions. Practically, none of which I tried worked, but still I found out some interesting things.
OpenLink Structured Data Editor:
OSDE is a browser plugin which aims at populating RDF graphs in the form of files, based on Linked Vocabularies. In my case it didn't work as my locally hosted ontology cannot play the role of a "Linked Vocabulary". However, OpenLink team said they will work on it.
OData2SPARQL:
In our test, the WebIDE did not manage to create the forms out of the box as suggested by the respective video tutorial. However, we managed to use OpenUI library as a client of the OData services automatically created by OData2SPARQL, providing a web service interface for our ontology.
Ontowiki:
In our test environment, OntoWiki partially worked. We could save data but there were some bugs when trying to add properties etc. OntoWiki developers said that they plan to refactor in order to actively support it in newer hosting settings, but this is not the case right now.
I'm new to building APIs, I made the first one using an MVC framework: codeigniter, with chris kacerguis rest implementation.
I'm not really sure this was the best think to do because I believe maybe the framework is not that "slim" or light just to API's purposes.
I plan to do a mobile App, an admin and a website so the three can consume the Api's services.
Is it a bad idea to have the API, the website and the admin on the same project? which are the pros and cons? or the best architectural approach?
Otherwise I will have: One Codeigniter project for the API and Another Codeigniter project for website and admin
thanks
You can create folders in "controllers" folder to organize your project and use the same project/env configuration :
controllers/Home.php
controllers/api/MyApi.php
controllers/admin/Admin.php
Edit : You will share models and libraries too.
In my project I realized 2 types of controller - REST and API. Admin js gui work with REST, other world work with API. You can do it simply with silex framework, a little brother of symfony.
The purpose of building a REST API so that you only have to build one project for your business model. This allows you to construct any number of applications on any platform, only requiring you to consume the API in different ways. This essentially separates/decouples the user interface from the business logic, and vice versa.
You should create separate projects for the REST API and each UI project should also be separated projects. This allows you to change the underlying code, language and platform in any one of the projects without breaking any of the other projects as long as the API signatures remain the same.
For example, you could have a live version of your website built using Codeignitor while developing another septate project using AngularJS. When your AngularJS project is complete you would simply swap out the project on your server (or create an entirely new website or server) still allowing you to use the other if required. Additionally, you may decide that you would like to move the API onto a different platform, language or database, develope it and swap the implementation when finished causing no changes to any of your UI projects assuming you have not changed the API signatures.
I am involved with a team that uses Xcelsius for their dashboard presentation design. I know of options provided by SAP to connect to the database. My team used flynet but lisence issues are pushing us to think of custom webservice. Can design a custom webservice (C# or Java) and use it with Xcelsius. I will realy like to know if its worth it or there are better options for my team. thanks
I was recently involved with an engagement that built out custom web services to both write new and alter existing records in the database. This was the only option for us as SAP does not provide any viable options to write back out of the box. Also, I don't think they (SAP) should but this was a unique requirement that necessitated the workflow.
The web services were in .net
Good morning,
I am taking over from someone who has been using the Entity Framework to communicate with a database. How this has appears to have been done is that there is a WSDL that describes all of the objects that we use created in Enterprise Architect. This is then imported as a Service Reference in Visual Studio.
I am a bit confused by this so was wondering if it is a sensible approach. The WSDL has a sample port, binding and service that appears to be not used at all in the code. Do these exist in order that the WSDL gets imported properly?
I looked on Google and couldn't see any examples of people creating from WSDLs in this way so wasn't sure it was a common approach.
So when this is done you have the representations of the data as classes. Then it seems you add them to a class inheriting from a DbContext which creates the tables in the database. Is this correct?
If you are using WSDL just to get data from EA to VS it is of course completely wrong. WSDL describes web service - port and binding are mandatory for service description.
EA Professional edition and above has direct support for code generation from the model. You just have to set which language you want to use (in Project browser select folder containing your classes and interfaces and set language in properties) and then you can use Tools > Source Code Engineering > Generate Package Source Code.
In a MVC application, what are some of the components that make up the application. What tools and functionality is missing that you would like to have. Regardless of the server-side language, what would you want?
I see a lot in my code where I code some much functionality that it seems should already be there. I looked at Google web toolkit and they seem to get it right. Widgets are widgets and you simply add them to your application.
For example. I work with J2EE apps but in other languages, the components are the same.
Controller Objects
Controller handlers, defined by methods in the controller objects.
Configuration files defining the URL mapping and settings.
Template server page files (e.g. JSP/ASP files).
Configuration files defining O/RM mapping between application objects and the database.
Configuration files defining the database connection properties.
JavaScript libraries (e.g. jQuery)
Logging configuration files
Resource message bundle files
Validation configuration files or code
Middleware components and objects (EJB configurations, JMS/Messaging configurations, etc).
Credit Card or other middleware connectivity APIs and libraries.
Anything else you can think of?
Built-in Unit Testing Component
I think one thing you're missing from that very exhaustive list is the automatic binding of request properties to form objects, and the saving of these objects to the session where appropriate. Form objects here being the object on the server that represents the current state of the HTML-based for displayed to the user.
I think scaffolding and automatic admin interfaces are very nice features too, that I dont want to miss ;)
You've made the assumption that all MVC applications are websites. MVC is widely used for more than just web apps so things like URL mappers, template server pages and "Server side" languages are not associated with the MVC pattern, so much as a particular implementation and adaptation of the MVC for use in web apps.