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
Related
I want to choose ATK (http://agiletoolkit.org) as my framework for easily build the admin part, I have 2 questions.
In their site, I see that the last blog post was a year a go.
Is this project continuing?
Should I use this framework in the site AND the admin? I am a bit confused about using it in the site side? Or maybe I should use another framework (which will create an overhead)..
Edit
I am a developer that is coming from JAVA and .net mostly.
I am a freak of service reuse because I have an experience on a large scale projects.
I see that ATK4 is not a classic REST based.
Lets examine this situation if I may:
Just as an example, I have a registration form that has a very complex logic in pre-insert and post-insert.
So it means that I need to create a REST api for registration (with all the complex pre-post logic).
BUT! the crud operation will not be arware for this complex logic in it, so I am creating some sort of a pit-fall when I cant re-use CRUD operation from the site and vice versa.
I am use to create single service that is suitable with admin CRUD and site operation, this way you wont have duplicate invocations, and each operation is aware to the permissions you have.
Thanks
Site is now in the process of complete rewrite. Their blog never was active enough.
BUT this project is very alive and very active. For all news you should check these resources:
GitHub repository - https://github.com/atk4/atk4. As you can see there are new commits almost every day.
Google groups for discusions - https://groups.google.com/forum/#!forum/agile-toolkit-devel Same story - new posts every day.
IRC - #atk4 at freenode
Stackoverflow - https://stackoverflow.com/questions/tagged/atk4
YouTube - video tutorials
some more resources for addons etc.
You can use ATK4 for whatever type of site you want. I guess it better suits for admin (backoffice) side, but can be used equally well in frontend too. It's just - learning curve can sometimes be not so short. On the other hand - when you get used to ATK4 style of coding, then it definitely sucks you in :))
Update on Agile Toolkit as of 2017:
In order to keep the best parts of ATK4 framework alive, I have started 2 open-source projects following best practices:
https://github.com/atk4/data - Agile Data - Refactor for models
https://github.com/atk4/ui - Agile UI - Refactor for UI
Additional resources (forum, blog, etc) can be found at http://agiletookit.org/.
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.
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.
I'm building a silverlight line of business application in silverlight 4 using RIA services currently and i'm finding RIA services to be more and more of a pain everyday..
A lot of the database interaction in this application doesn't follow the usual CRUD pattern and some of the data just doesn't "fit" with the RIA services style of doing things..
Even more importantly it doesn't fit the way my brain thinks about web services!
(I think that abstraction often gets in the way of the business problem you're trying to solve)
It's got to a point where a scary chunk of the code base is workarounds for the object context and spoofing ID's to create some kind of unique key etc..
I'd also like to swap out entity framework for rob conery's massive (he thinks the same way as me about abstraction, dynamic typing etc..)
Are there any alternatives which work using dynamic typing and JSON?
If not I may have to roll my own!
Have you looked at WCF Data Services?
http://msdn.microsoft.com/en-us/data/bb931106.aspx
You might also find that WCF Web APIs suits you better.
http://codebetter.com/glennblock/2010/11/01/wcf-web-apis-http-your-way/#0_undefined,0_
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.