In my application have at least 3 layers/tiers; like Data, Business, Web.
As the project was created in xproj format, I'm seeing the "Data" references in the "Web" tier.
This was not happening in csproj. How do I isolate better?
Related
Our old application had a middle tier which held business logic and talked to the db, it then talked to 2 clients, one Winforms and one Asp.Net, neither of which knew anything about what kind of database it was speaking to. It used DataSets and DataReaders.
What's the modern equivalent? Are tiers still needed?
There's plenty of questions and answers out there but they all seem a little dated. I'm getting the impression that it should be a tier with Web API and the entity framework which talks to a separate WPF client and something like a Angular JS client.
I'll happily buy a few books if someone could suggest some
For anyone else new to the entity framework. The difficulty here was that the web is full of advice that was correct at the time but becomes out of date. So, for EF6...
There are posts online in which Self tracking Entities were advised (Aug 2013), e.g.
Entity Framework not saving modified children
however they have since become deprecated.
https://msdn.microsoft.com/en-us/data/jj613924.aspx
A page that covers the valid approaches is:
https://msdn.microsoft.com/en-us/data/jj613668
which mentions: Web API, WCF Data Services and also a 'roll your own' approach. The latter is covered in the book 'Programming Entity Framework: DbContext by Julia Lerman'.
Assuming you go down the Web API approach there's an example here:
http://www.asp.net/web-api/overview/data/using-web-api-with-entity-framework/part-1
I'm trying to develop a hybrid app which will deliver a range of simple teaching material to the user. I am planning on using Telerik App Builder in conjunction with Cordoba 3 to create the app. What I cannot decide is how best to package the actual content into the application. I'd like to achieve a separation of the content from the code, and just combine the two when building the delivery packages. (The content is being prepared by a subject matter expert.)
Is there a way I can use Cordova or Telerik AppBuilder to pre-populate a SQLite database as part of the app install process? Or am going about this in completely the wrong way? I have been researching this in the Telerik documentation but without success so far. If someone could point me towards a suitable example or even the correct places in the Telerik or Cordova docs I'd be very grateful!
I recently ran a techie webinar on the topic. The main idea is that you need a centralized system to host this content and this system needs to expose some kind of a service layer that will feed content to your app. To me this seems like a very growing market opportunity, but feels kinda the same as the web 1.0 days where all of us were trying to figure out how to feed cotnent to websites and everybody was building their own CMS in a way.
Telerik Backend Services provides an editing interface, so it can fit some requirements, but it's not a publishing system, plus you may not want to pay developer licenses to your back-end users or provide them with access. The premise of the webinar I am talking about was that we discussed how to integrate with another telerik product - Sitefinity to do this job for you instead. The first 20-25 minutes are an overview of the platfrom, so if you have seen it already, you can certainly jump to ~;0:25 to see the rest
http://www.sitefinity.com/campaigns/webinars/build-content-driven-mobile-apps
Now certainly it doesn't have to be Sitefinity or CMS for that matter, Sitefinity provides a bunch of App Builder related features that are handy, but you technically have a few options:
- Build your own applicaiton and back-end.
- Use any type of CMS or platform that will give your SMEs the back-end interface to publish and the service layer to expose to the app. In the webinar I also go through some neat tricks such as using push notifications upon publishing.
This way you get a clear separation of content and code - you can even get a separation of content structure and code, which is an idea i talk about in greater detail.
I hope this helps!
Svetla
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.