I'm looking at the ProjectTracker CSLA example solution and it has projects for DAL, EF implementation of DAL, and a project for the business objects/rules/etc.
I understand it's good practice to split logical separations in to projects, buy my concern is is there really a problem putting the DAL and EF into the business assembly?
It seems that build time is most affected by the number of projects.
The app I'm working on would likely have 18 or more projects if i followed the examples layout.
I know i can make multiple solutions to help mitigate this, but I don't want to go down this path right off the start.
Thanks.
Multiple projects are recommended, and are necessary to get the full benefit of CSLA and its n-tier architecture.
If you know beyond the shadow of any doubt that you will never need n-tier deployment, never need advanced security, never need increased scalability, and generally aren't looking to build an enterprise level app, then you can use fewer projects.
In fact, if you are building an app that you know you'll deploy as a 2-tier app then you can put the business classes and data access classes directly into your UI project along with the UI code.
Is that a good idea? No.
Will it work? Yes.
To piggy-back on Rocky's answer, the company I work for uses CSLA, and we originally had all DAL code in our business classes. We were on Oracle 10g as our dbms at the time, but wanted to switch to SQL Azure (and we had a pretty big system upgrade and schema changes simultaneously). So, we did the following:
Implement the DAL interface as a project
Implement 2 DAL projects, one each for Oracle and SQL (actually 3 w/ a mock db, but that was more for proof of concept)
This let us test the conversion in both databases simultaneously. If we had started with the DAL project to begin with, this would have been a lot easier to accomplish.
Long story short, it may take more time, but unless you're positive of all of Rocky's points, it's worth it.
Related
These are more high level questions, but our team is new to developing with APEX. We are currently a team of 3. We are using APEX 19.2, but are planning to upgrade up to 21.1
How do others handle the development flow, versioning, and releases of their projects when working in APEX?
We put majority of the business logic (validations, source sql, and process handling) in packages. So I feel it is pretty easy to version those files as they are outside of the APEX UI and can version in Git accordingly, but how do others version control all the APEX UI changes (pages, regions, items, DAs, etc...)?
I've searched and haven't really stumbled upon best practices of how teams, that use APEX, conduct their development process. One thing I'm nervous about is branching changes inside APEX UI. Sometimes we are given a requirement (say A) and we are asked to hold that release, but start working on requirement B. We may even release B before A gets final approval.
Are there any best practices, to ensure that developers working in the same workspace do not collide with others work? Luckily most of our project tasks do not overlap, but curious how others handle this
Any links or tips to this would be appreciated as we are new to APEX and trying to work these things out up front.
I'm probably not the right person to answer as my Apex team consists of 1 (one) member - me.
However:
We put majority of the business logic (validations, source sql, and process handling) in packages.
Me too, I found that to be the best option. Keep as little code on pages themselves as possible.
As of team development, did you read Managing the Application Life Cycle with Team Development?
Tracking Features might be particularly interesting for you. For example, it contains
Approval status of the feature. Indicates if the feature is to be implemented and the current progress.
which sounds like what you asked for.
I hope that someone - who really works in a team - will see your question and answer; I'd be interested in reading about their experiences and suggestions as well.
When we export application as zip , we can see there is folder structure. So in git we have to follow the same directory structure so it is easy to review and for versioning.
Thanks,
Nagaraju P
I'm working on legacy code in a DotNetNuke module, trying to get classes and behaviors under a testing framework: I'm taking this opportunity to follow advice from the "Working effectively with legacy code" book, so what happens is that i'm trying to define areas which can be tested thoroughly and then converted to services. Then i'd like to use an IoC framework for it to work. For now, i've set eyes on Ninject.
However i'm hitting a design problem: as i'm in a DotNetNuke module, i can't really change application-wide structure: for example i can't derive the Application from NinjectHttpApplication. I can't use these suggestions from SO either.
I was thinking about having the Kernel in a static class that my module would set up and then use but from what i've read around it's a very bad idea.
So i'm starting to ask myself if it's possible to use an IoC in an application that hasn't been set up to support it from scratch. If i'm supposed to have a whole dependency tree loaded for each request, how can i rewrite legacy code locally and benefit from IoC? Is there a pattern where IoC use can grow out from very local rewrites?
Even though i'm working with DotNetNuke, any standalone component that can be installed into an independent framework begs the same question. Also i'm not targeting Ninject specifically, if another IoC framework can help in this case i'm willing to consider it.
From my experience, your best bet to get this type of abstraction within the context of DotNetNuke is by using the WebFormsMVP framework. This is really the only sane way I've found to do unit testing in a DNN module, and if memory serves I spent awhile trying to wire up Ninject a year or so ago.
But be warned, it is still WebForms and will never be drop dead simple. And without knowing your existing code base, I'd have a hard time knowing how easy it will be to make the migration.
I have a couple of resources on GitHub that you can check out for reference:
The first is a module template that should act as a solid starting point:
https://github.com/irobinson/WebFormsMvp-DNN-Module-Template
The second is a small example project:
https://github.com/irobinson/BeerCollectionMVP
Depending on the version of DNN you're using, it may or may not already ship with WebFormsMVP, but you should be able to either bundle the dependencies w/ your module or upgrade to the newer version of DNN if that's reasonable.
I have looked for similar questions, but could find none other than the difference between solutions and projects. Mine is on the same level, I suppose, but is slightly different.
I'm a previous Java developer thrust into C# recently and I am the sole individual charged with setting up source control, project standards, etc. etc. and this is my first go with Visual Studio (using 2010 Pro).
I understand a solution is a "container" for related projects, but I am unsure the best practices of adding projects to a solution which are related, but are of a different type.
For example, would I place a web project in the same solution with a desktop application or mobile app if they are related (rather near identical) in function? They are basically the same app, but in different formats. They may use the same classes (for a contrived example, a Person class).
To me, they seem obviously related, but are different applications, so it would seem they should be in different solutions.
I appreciate any feedback offered.
Thanks in advance.
Those apps should be in one solution, expecialy if they share functionality, common projects etc. Quite good approach is to group projects within a solution using solution folders, for example "Common", "Web", "Mobile", "Setup" etc. This way you can have logical groups inside solution.
I would place them in the same solution, since this makes it easier to have a common class library as one project in that solution.
There are no rules for this so there is no right or wrong answer. It all comes down to how you want to organize your code. We commonly have web apps and console apps in the same solution because they are functionally tied together and share code so the type of project really does not matter.
I would place them in the same solution. You can create different configurations to build each application or build both of them at the same time. This allows you to change the class and verify changes made to the class will work for both applications.
Also if you start to see functionality start to duplicate across applications it is easier to create new classes and project that can apply to both applications.
You can throw everything in one solution. This is convenient if you often have to debug the library and application code together, but if the solution has many projects it can become unwieldy.
One approach is to treat the solution as 'that which will be installed as a unit.' Then your common library will go in one solution, and your mobile and desktop apps in their own solutions. This keeps solutions smaller, but it can be inconvenient when you are developing everything together-- so it works best when the library is very stable.
I am at a company that does not understand the concept of using frameworks and the benefits of them. I have tried to explain that it provides structure and organization but the people I am trying to explain to are still a little fuzzy about it. In your opinion, what is the best way to describe a framework in the most simplest terms and how it could overall benefit a company to transition their code from procedural and spaghetti code to a nice organized framework?
Thank you for your time.
I guess the best explanation I can think of for using a framework are to standardize your design process and save yourself a lot of effort as your code-base grows. Not to mention that a lot of work can be taken care of for you by the framework (which could save hours of coding). A framework can give you all the parts you need to build your application, you just have to assemble them.
The best reasons I can think of for using a framework are:
Code reuse -- If you try and follow the design of the framework you can save yourself a lot of coding time. However, some frameworks do require a time investment to master.
Encapsulation -- You can change the underlying implementation of different parts of the framework in a way that doesn't require a lot of code rewriting.
Extendability -- You can extend the code of the framework to add features you need and if you are careful about your design, you can reuse these features too.
I'm sure there are many other good reasons, but I'm sleepy.
EDIT: A good example of the benefits of a framework can be replacing the database adapter with another ie. switching from mysql to postgresql. This could be awful with functional programming but a framework could make this transition very easy.
Your coworkers most likely already use libraries, which one could define as code that exists outside of your project, and is meant to used in many projects.
A framework is like a library, but usually has other featues, such as
It might enforce changes to your code. For example, you wouldn't replace one method of your WebForms project with a call to the ASP.NET MVC framework - the entire project would be written differently to conform to the framework.
It might restrict the universe of applications that you can write. For example, you might be using a CRUD generating framework that lets you make data entry applications, but wouldn't let you make a video editing application.
However, a framework will usually give you a lot of value in return.
Let them do as they like ,first.
then pick up their shortcomings and
finally generalise your framework to avoid procedural code.
I'm going to concentrate on only a part of the question:
In your opinion, what is the best way to describe a framework in the most simplest terms
Framework == Library + Inversion of Control
Well I am new to this ORM stuff. We have to create a large project. I read about LINQ to SQL. will it be appropriate to use it in the project of high risk. i found no problem with it personally but the thing is that there will be no going back once started.So i need some feedback from the ORM gurus here at the MSDN. Will entity framework will be better? (I am in doubt about LINK to SQL because I have read and heard negative feedback here and there)
I will be using MVC2 as the framework. So please give the feedback about LINQ to SQL in this regard.
Q2) Also I am a fan of stored procedure as they are precomputed and fasten up the thing and I have never worked without them.I know that LINQ to SQL support stored procedures but will it be feasible to give up stored procedure seeing the beautiful data access layer generated with little effort as we are also in a need of rapid development.
Q3) If some changes to some fields required in the database in LINK to SQL how will the changes be accommodated in the data access layer.
When it comes to Linq-to-Sql vs Entity Framework, I strongly suggest to use Entity Framework. With the release of .NET 4.0 and VS2010, Microsoft added soooo much goodness in Entity Framework(EF) 4.0. Let me just mention a few points: POCO and NTier support (this means that you can have a separate library with your simple entity classes and of course EF will still be aware of them), Lazy Loading, Sql query optimizations...Also you can let EF to generate your entities (and you have the option modify the T4 generation template) or you can create them by hand if you need more control. Also, if you app will indeed be large, with EF 4, now you can separate your layers quite nicely(you can create your Mocks fo testing etc...). I'm not a web developer, so I cannot give you any hints on mvc2 on this matter.
q2-q3) - in EF you can have precompiled queries - IF you observer later on that query performance is not quite what you need. This will speed-up things quite a bit. If you plan to use EF and if you add a few changed to you database, you can easily update your model with a click.
I know I babbled too much on EF and not Linq to sql :), but hey...I believe this suits way better on your needs and you should definitely check it out for this project. Also, I don't know how much Microsoft will add features / invest in LinqToSql in the future.
Cheers,
ok precompiled queries that certainly is catching my attention.