I have the task of developing a custom ASP.NET business application. It will essentially consist of record entry and a workflow to manage these records. We are looking to leverage a CMS and we've selected DotNetNuke at this point. I'm wondering how we can leverage an ORM such as Entity Framework so that when we make changes to the model we only make changes in one location?
If we have highly customized forms on the front-end and want to make a change such as add a new field, how can we minimize development time for that? Flexibility building forms is extremely important for our application. I don't think we can use ASP.NET MVC which has the EF code-first pattern, where we would just make changes to the POCO and generate the script to changes the database and the view pages. So I'm wondering if there's anything in DNN that offers this level of abstraction?
ASP.NET MVC's portion of this would not readily be possible within DOtNetNuke, however using EF Code First can be done at the data/business tier and then you handle the rest of the UI youself.
You will not have scaffolding for the UI, but in most cases scaffolding is not enough to get what people need anyway.
Related
I am currently developing an ERP solution for a company. The requirements are as below :
They need one winforms based application which will take care of modules like HR, BSC, Inventory etc.
A web based solution that needs all employees to get access to their personal data, apply for leave etc. This needs to be an internet based solution which can be accessed from anywhere.
In future they also want a document management system which will be web based.
Right now we are already through with some modules in winforms application as that was the urgent requirement. For winforms we have taken a horizontal approach for layered architecture. i.e. each module is one project with its own datalayer and businesslayer within project. Now I need to start working on the web solution. I am just wondering which approach will be best approach to share the datalayer and model layer between the winforms app and web app. Also the web app needs to have proper security in place as it will be sensitive data. I have thought about 2 approaches which may not cover all possibilities available.
The approaches I can think of are as below :
a. make a web service which will take care of datalayer and models. host it on the server and access it through winforms app and web app. For this I will need to change the coding that I have already done. But it is acceptable as it will require minimum efforts as its a layer architecture. here the only doubt I have is, for winforms app it will unnecessarily go through the web service layer and make it slower.
b. Convert the datalayer and models into dlls. Access these dlls in winforms and web app.
Also regarding the web app which will be the better approach :
a. Should I go for MVC3 based web app.
b. OR asp.net and WCF?
The situation is that I am working on this project along with a colleague and we are the team of just 2. So we are the ones taking decisions about everything.
I have fairly good experience in winforms but comparatively less experience in web based technologies. I will really appreciate your opinions on this.
If you want your model types to correspond closely to your database schema, you could create them using the Entity Framework designer and the Self-Tracking Entities template. This will allow them to be easily serialized with changes via WCF and persisted to and from the database. You then have the option of either creating a custom WCF service to deal with the entities or could exposing your Entity Framework context directly as a service using WCF Data Services (OData).
As far as the presentation layer goes, the two choices you listed are not mutually exclusive. You can have MVC with WCF, MVC without WCF, WebForms with WCF, WebForms without WCF... Since you are going to need to create the service anyway, and MVC seems like the way to go these days, I would probably recommend an MVC application that uses your WCF service to access the data.
There is a medium size database application that needs to be built featuring a web interface. The platform is asp.net 3.5 (asp.net mvc 2), sql server and ext.net 1.3.0. The tool is visual studio 2010.
I wonder, should I start with the database design and business logic and move on to the UI when I've a complete working draft/skeleton? Or should I build the database and BL step by step and bind them to the web UI as I progress?
Even more specifically, should I construct the whole BL functionality as a separate dll project and then have it referenced by the web application project? If so, what communication options do I have? web services, for example?
Last but not least, the web application requires a security mechanism (user accounts etc). Should I design and integrate it right from the start or can I add it when everything else is ready?
(I hope my question is clear enough. As far as I know, creating a dozen or more aspx pages as a means of building and testing the application functionality leads to all shorts of problems and dead ends while being extremely time consuming. What I seek is a way to separate the UI from everything else. Something like having a working prototype to show case to the customer and have the (ext.net) web UI built later as a completely separate step.)
Is there a particular reason why you are not planning on using .NET 4.0 and MVC 3? MVC 3 comes with the razor view engine, which produces much nicer and cleaner views. And if you use .NET 4.0 you can use the Entity Framework. The new Entity Framework 4.3 lets you use code first with migrations, which might be a good way to go in a project where you need to "explore" the requirements in collaboration with the customer. Using code first you build your model using POCO classes and let EF take care of the database schema. This is effective if you make lots of changes to your model, which it sound like you might want to. Check out this video for a good introduction to code first with migrations.
I am planning an application which will have a web based component and a desktop client component. Basically I am planning to create the web based component using ASP.NET MVC3 & Entity Framework as a normal data driven website, however I am also planning to create a desktop client that will extend the functionality of the website, this is new territory for me and I am somewhat confused. I know that the best way to create an application that needs to access a central database is using WCF, however I have not used WCF before but have heard that it easily integrated with Entity Framework.
So I know that what I want to do is certainly possible I am just looking for some guidance for how the seperate components of this application should glue together, etc should I be working with WCF and Entity Framework first? Or should I complete the web based componenet before working with WCF?
Thanks,
Alex.
There are lots of ways to do this and all these ways have different level of complexities. For example, you could just build your web-application using Entity Framework, in the same web-application you expose an OData service (WCF Data Service) which provides a RESTful service that your WPF app can use to access the database. This is fairly easy, since WCF Data Services work really nicely with Entity Framework. This is basically a two-minute job (if you are not doing anything fancy). Your WPF application then has basically the same type of access to the database as your web-application does. In it's default configuration the WCF Data Service simply exposes a EF ObjectContext and allows the same type of operations on it. I would recommond you try this out and see for yourself if it fits your requirements.
But, this approach is basically a shortcut to allow a desktop application access to your database. Which in most cases, is perfectly fine. If you do want to put some effort into it, you could model a service-layer which either uses a Entity Framework data source or a OData data source. From here on in, it's all about design patterns. Which comes at a cost; separation of layers is a hard thing to do, if you want to do it right. Given that the .NET world as somewhat changed to "get the job done", it's fine to put those bits together and get a running app in no time.
You should also consider that the MVVM in WPF and MVC in a web-application have fundamental differences; where a MVC app just pulls a "snapshot" out of a database, a WPF application might need more effort and asynchronous programming to feel natural.
I can provide you with some guidance for specific tasks, like how to decouple the WCF Data Service and Entity Framework, but from my experience, the overhead of "doing it right" is enormous. If you are comfortible without a service-layer you will have a lovely experience working with EF and OData.
It is better you start with the web component first integrated with wcf, you can use entity framework, but i would recommend using T-Sql itself if you have a data heavy DB and it gives you lot of options for performance.
I would recommend you build the application model using MVP pattern as it makes it easy to switch from a desktop to web application and also inline with your requirements of extending it.
We are starting out with the development of a Silverlight app that will make use of Windows Workflow Foundation (WF4). Our workflows are long-running. We plan to use the tracking and persistence functionality of WF. We will probably need to also store data related to each workflow instance in another DB (I suspect running reporting against the workflow persistence store would be tricky). Our workflows may change with time so we would probably also need some strategy to implement versioning on them.
So specifically, are there any resources you can point me to or direction you can give me on where to start, taking into account that we need to implement tracking, persistence and versioning of workflows?
Based on your question, I'm assuming that you already have experience with WWF and are really just asking about how it interacts with Silverlight. The short answer is that it would not be noticeably different from how you would implement a WWF-enabled application in traditional ASP.NET. Remember that Silverlight is only a UI client that usually lives on top of a traditional ASP.NET web application. Your WWF-related logic and code would live in the ASP.NET layer -- not in Silverlight at all.
So if you already know how to make a WWF-enabled application in ASP.NET, all you really need to learn is how to wire up a shiny Silverlight interface to an ASP.NET web app. For that, you of course only need to hit up http://silverlight.net/, which you're probably already doing.
Good luck!
I'm starting to jump in to WP7 development and I have a few questions. My current background/experience is with ASP.NET. I'm new to Silverlight as a whole, so I have some questions regarding the architectural design of the application. I don't have experience with MVC, and it appears that Silverlight is based off of it. Is that true? To my original question:
Once the new developer tools come out, the app will have a SQL CE back end that, as a future release, will sync with SQL Azure. I'd also like to provide a web based application that performs the same functions, and interacts with the Azure database. I'm wondering how I should structure the app to minimize any code duplication.
I was thinking of using a generic n-tier architecture. UI > Business Layer > DAL (LinqToSql) > Sql. These classes could get re-used on the web too.
Silverlight is not really based on MVC. In fact, you can implement any architectural pattern as long as you fully understand its functionality. Most people prefer MVVM, which is similar to MVC, the only main difference is that the controller is replaced by the ViewModel that plays the role of an intermediary data link between the model and the view.
With the release of Mango, you will indeed have access to SQLCE. In your case, since you are planning on using specific interoperability layers, I would recommend building both applications in Silverlight with an intermediary web service that will communicate with the data storage (in your case it will be Azure). You win in two points:
You are using Silverlight, which means that you can use a similar codebase (with platform adjustments, of course) to deliver the same functionality.
The web service is app-independent. Therefore if you ever decide to build, let's say, an iOS application, you will be able to use the same communication layer without major changes.